System, method, and apparatus to support mixed network communications on a vehicle

ABSTRACT

An example system includes a system comprising a vehicle having a first network and a second network; a first device on the first network; and a converged network device (CND) interposed between the first network and the second network and structured to facilitate communications between the first device and the second network; wherein the first network is of a different type than the second network.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of and claims priority to U.S. patentapplication Ser. No. 17/027,167, filed Sep. 21, 2020 entitled SYSTEM,METHOD, AND APPARATUS TO SUPPORT MIXED NETWORK COMMUNICATIONS ON AVEHICLE (SONA-0006-U01).

Application Ser. No. 17/027,167 (SONA-0006-U01) claims benefit ofpriority to the following provisional applications: U.S. ApplicationSerial No. 62/903,462, filed Sep. 20, 2019 entitled SYSTEM, METHOD ANDAPPARATUS FOR A MIXED VEHICLE NETWORK (SONA-0001-P01); U.S. ApplicationSer. No. 62/911,249 filed Oct. 5, 2019 entitled SYSTEM, METHOD ANDAPPARATUS FOR A MIXED VEHICLE NETWORK (SONA-0002-P01); U.S. ApplicationSer. No. 62/911,248, filed Oct. 5, 2019 entitled SYSTEM, METHOD ANDAPPARATUS FOR CLOUD-BASED INTERACTIONS WITH A MIXED VEHICLE NETWORK(SONA-0003-P01); U.S. Application Ser. No. 62/986,444, filed Mar. 6,2020 entitled SYSTEM, METHOD AND APPARATUS FOR IMPLEMENTING CONFIGURABLEDATA COLLECTION FOR A VEHICLE (SONA-0004-P01); and U.S. Application Ser.No. 63/024,383, filed May 13, 2020 entitled SYSTEM, METHOD AND APPARATUSTO TEST AND VERIFY A VEHICLE NETWORK (SONA-0005-P01).

Each of the foregoing applications is incorporated herein by referencein its entirety.

BACKGROUND

Vehicle communication networks are utilized to connect sensors,actuators, controllers, and communication devices throughout a vehicle.Recent trends have been increasing the burden on these vehiclecommunication networks, with more devices being connected, more datapassing between devices, lower latency requirements to meet vehicleperformance, safety, and emissions requirements, and added vehiclefeatures. Additionally, consumers expect increasing connectivity andfeatures that increase the burdens on vehicle communication networks.These trends are expected to continue, and to accelerate, for theforeseeable future.

Traditional vehicle communication networks (CAN, LIN, FlexRay, MOST,LVDS, etc.) suffer from a number of drawbacks and challenges. Thesevehicle communication networks have been developed to meet theparticular challenges of a vehicle environment, and have accordinglydeveloped separately from other networks, such as computer local areanetworks, wide area networks, massively interconnected networks (e.g.,the internet), and wireless networks. Most vehicle networks consist of adata link layer and an application layer, utilizing robust and dedicatedequipment such as a Controller Area Network (CAN) bus, with dedicated orshared wiring between devices utilizing specific data protocols (e.g.,J1939, OBD, etc.). A modern vehicle may have multiple network buses,with specific commands and communications available, and limitedcustomization and data speed available. E.g., CAN buses typicallyoperate at up to about 1 Mbps, with high capability CAN buses operatingup to about 10 Mbps. Additionally, CAN buses experience latency greaterthan 25 ms, and generally higher from about 60 ms to 500 ms, dependingupon the configuration, the traffic on the CAN, the priority forparticular messages, and the like.

As the number of devices and the data rate demand from the devicesincreases, traditional vehicle communication networks require theimplementation of higher performance buses . Because the automotiveindustry is a high volume industry with a very low tolerance for failureof components, automotive manufacturers utilize the same components fora long time, and across a broad range of vehicles—including sharing ofcomponents across manufacturers. Additionally, a change to a nominallymore capable component may introduce risks, integration costs,re-certification burdens for a given application, or have otherundesirable consequences to the system. Accordingly, even if vehiclecommunication networks transition to a higher capability networkconfiguration, it is desirable to keep network types segregated in thesystem, and to keep a large number of legacy devices (e.g., CANcompatible) in a system for a long period of time.

Data collection from vehicles includes a number of additionalchallenges. For example, data collection operations are subject toregulation and liability risks, especially with data collection that mayinclude private information, personally identifiable information, and/orliability related information. Data collectors, including entities thatmay have ownership or possession of sensitive data are subject to riskwhile holding data, for example in the event of inadvertent or maliciousaccess to the data. With regard to vehicle data being collected, a largeamount of data may be collected, and a large number of purposes forcollecting the data may be present, increasing the risks relative toother general data storage applications. Accordingly, it may bedesirable to control data collection, storage, and access, to reducerisks, and it may further be desirable to include verification of dataaccess, partitioning or other exclusion of data when the data is notbeing used, and the like.

Data collection for vehicles is further complicated by the amount andtype of data to be communicated between the vehicle and externaldevices, where the network system of the vehicle is limited byconstraints of a mobile application, expenses and/or bandwidthlimitations incurred by high data rates and/or large data transfers.Even in light of the foregoing, customer demands, market expectations,increasing requirements for efficiency of vehicle operations, and theincrease of functional capability for data related applications arecontinuing to proliferate the aggregate amount of data to betransferred, the number of off-vehicle applications utilizingtransferred data, the number of purposes that the data may be utilizedfor, and the number of users or entities having a legitimate need forportions of the transferred data. Additionally, applications utilizingthe data continue to increase in sophistication and capability,increasing the data demand for the limited available transfer resources,and increasing the cost and complexity of logistical control and storageof the transferred data. For example, higher capability pathing oroperational algorithms related to the vehicle, increasing automation ofvehicle functions, increasing demand for prognostic determinationsand/or maintenance support, and increasing media streams (both thenumber of media streams and the quality of those media streams) alldrive for increased demand in data rates, stored data amounts, and thenumber of entities or applications accessing the stored data.

SUMMARY

The description herein references vehicle applications as a non-limitingexample and for clarity of the present description. However, embodimentsherein are applicable to other applications having similar challengesand/or implementations. Without limitation to any other application,embodiments herein are applicable to any application having multiple endpoints, including multiple data sources, controllers, sensors, and/oractuators, and which may further include end points present in distinctor distributed network environments, and/or applications havinghistorical or legacy networking or communication systems that may betransitioning (within a given system, as a class of systems, and/or asan industry) to newer and/or more capable networking or communicationsystems. Example and non-limiting embodiments include one or more of:industrial equipment; robotic systems (including at least mobile robots,autonomous vehicle systems, and/or industrial robots); mobileapplications (that may be considered “vehicles”, or not) and/ormanufacturing systems. It will be understood that certain features,aspects, and/or benefits of the present disclosure are applicable to anyone or more of these applications, not applicable to others of theseapplications, and the applicability of certain features, aspects, and/orbenefits of the present disclosure may vary depending upon the operatingconditions, constraints, cost parameters (e.g., operating cost,integration cost, operating cost, data communication and/or storagecosts, service costs and/or downtime costs, etc.) of the particularapplication. Accordingly, wherever the present disclosure references avehicle, a vehicle system, a mobile application, industrial equipment,robotic system, and/or manufacturing systems, each one of these are alsocontemplated herein, and may be applicable in certain embodiments, ornot applicable in certain other embodiments, as will be understood toone of skill in the art having the benefit of the present disclosure.

The disclosure herein, as reflected in the described embodiments, hasrecognized that the complexities and other challenges set forthpreceding have synergistic effects that cause the complexity of thevehicle data environment to be even greater than the sum of theindividual contributions from each challenge.

As one example, the increasing number of entities or applicationsaccessing the data increases the likelihood that individual datarequests will overlap—for example with multiple entities requesting thesame or similar data. Further, the increasing number of entities orapplications accessing the data increases the likelihood that members ofthe accessing group will share similar authorization levels, such thatthe data access for individual members of the entity or applicationgroup will benefit from data management.

In another example, regulations regarding sensitive data are increasing,which increases the data management requirements of the systemgenerally, but also increases the likelihood that data management may besubjected to multiple constraints at a given time, and/or changingconstraints over time as regulations change, and/or based on therelevant jurisdiction(s) that may change as the location of the vehiclechanges.

In yet another example, the complex environment of presently known andtransitioning vehicle network architectures—for example vehicles havingmixed network types and/or partitioned networks—increase the complexityof data access for individual entities that, without certain aspects ofthe present disclosure, may otherwise be required to determinerequesting parameter specifications for particular data elements, and toupdate those requesting parameters as vehicle network architecturesevolve. In view of the increasing number of entities requesting dataaccess, the aggregate cost to the automotive support market increasesnon-linearly, as each of the entities incurs the costs to trackrequesting parameter specifications. Additionally, the trajectory ofadditional entities requesting data access is moving toward entitiesthat are positioned further away in the technological knowledge spacefrom core automotive functions, and accordingly the intricacies andidiosyncrasies of vehicle and/or automotive applications, includingon-vehicle network configurations, specific data descriptions, datarequesting and communication protocols, industry standards or customsfor presenting information, and the like, are becoming less well knownon average for each incremental new entity, further increasing the costvolume function (e.g., the cost over time for a given entity to meetdesired data collection deliverables, where the given entity may be anautomotive manufacturer, and/or a vehicle market, a geographic market,and/or an industry such as the automotive industry, the passenger carindustry, etc.). For example, consider a notional cost volume functionsuch as:

COST=# of entities*basic learning cost*adapting to transition costtrajectory*data trajectory cost*regulatory adaptation cost*dataaccess/storage liability cost

The described COST function is a non-limiting notional example todemonstrate how various challenges and complications with regard topresently known systems interact and synergize to increase the costs tomeet future data collection functions for vehicle applications. The costparameters described are not intended to cover all costs related to thechallenges present for the automotive data collection industry orpresently known systems. Parameters may be averages or other complexfunctions, and the values of particular parameters will generally not beknown with specificity. In addition, the units of the COST may beexpressed in monetary values, as a resource (e.g., engineering hours,computation time, etc.) to meet data collection targets over time, asanother non-monetary unit such as equivalent emissions, customersatisfaction, risk incurred, public perception losses or gains, etc. The# of entities parameter reflects generally the number of entitiesaccessing vehicle data over time; the basic learning cost reflects thecosts for new entities to learn the specifics of data collectionrequirements and protocols for a specific vehicle, vehicle type, market,etc.; the adapting to transition cost trajectory reflects the costs toadapt to changing vehicle network configurations, including networktypes and organization, and interactions with end points or devices onthose networks; the data trajectory cost reflects the increasing demandfor data collection from relevant vehicles over time, including datacommunication, storage, and resulting functional consequences such asnot being able to support a desired application or costs to enhance datacommunication infrastructure; the regulatory adaptation cost reflectsthe costs associated with an increasing number of regulations, anincreasing number of regulatory frameworks, and/or an increasing numberof regulating entities; and the data access/storage liability costreflects the costs incurred for compliance and security of data, and/orlosses incurred due to data breaches, unauthorized use, prematureexpiration of data, or the like.

Without limitation to any other aspect of the present disclosure,aspects of the disclosure herein reduce and/or eliminate any one or moreof: a cost per entity added to a data collection system, a basiclearning cost for a new entity to implement an application utilizingcollected data, an adaptation cost to changing vehicle networkconfiguration(s), a cost incurred to meet the increasing demand for datacollection, a cost to adapt to a changing regulatory environment, and/ora cost to secure data and/or losses incurred for breaches orunauthorized use. Certain embodiments and/or aspects of the disclosureherein may address one or more of the described cost parameters. Certainembodiments and/or aspects of the disclosure herein may increase one ormore given cost parameters, but nevertheless be beneficial by decreasingthe overall cost function for a target vehicle, vehicle type, entity,industry, etc. Certain embodiments and/or aspects of the disclosureherein may increase one or more given cost parameters, but provide otherbenefits such as improved functionality. In certain embodiments,improved functionality may be achieved at an increased cost, but at alower cost than previously known systems configured to achieve a similarimproved functionality.

Without limitation to any other aspect of the present disclosure,embodiments herein provide for operation of a system having multiplenetworks thereon, with end point devices distributed across networks,and provide for operations utilizing data, communications, and/orcommands with end point devices without requiring specific knowledge ofthe locations, capabilities, and/or data configuration for at least someof the applications, circuits, and/or other operators within the system.Embodiments herein provide for configuration of network management,allowing for changes in end point device locations within the system,adaptation to system failures or off-nominal operations, and/or updatesto the system that may occur during stages of manufacturing, bodybuilding, service, upfits or upgrades, replacement of parts,maintenance, campaigns, changes in parts, and/or changes in industrystandards. Embodiments herein provide for monitoring of network statusand/or performance for networks on the vehicle, including monitoringwhen the vehicle is intermittently connected to an outside device.Embodiments herein provide for configuration changes to the monitoringoperations, including changes in the networks monitored, parametersmonitored, execution of monitoring events, and the like. Embodimentsherein provide for monitoring operations of end point devices, networkcommunications, communications between specific end points (on the sameor distinct networks), and configuration of these. Embodiments hereinprovide for network traffic control, regulation, and/or support, both ona particular network, or between networks. Embodiments herein providefor selected distribution of network management, monitoring, and controlfunctions, including providing for incorporation of functions withinexisting controllers, distributing functions between controllers,providing for redundancy and off-nominal operation support, variationsof these between similar systems while supporting full functionality,and combinations of these. Embodiments herein provide for monitoringoperations of end point devices, network communications, andcommunications between specific end points, where a monitoringapplication or device communicates with a first network, and monitors asecond network. Embodiments herein provide for monitoring any network,network zone, flow, device group, virtual group, or the like that may bepresent within the system.

Embodiments herein include operation of a mixed network system toprovide for application mission support including control, monitoring,data collection, configuration, and/or updating. Embodiments hereininclude allowing for active control of devices, end points, controllers,flows, device groups, functions of the vehicle, applications of thevehicle, or the like, which may be on any network of the vehicle and/ordistributed across more than one network of the vehicle, and fromdevices, applications, or controllers that may communicate with anynetwork of the system. Additionally or alternatively, embodiments hereinmay support active control of devices after changes to the controlleddevices, end points, controllers, flows, device groups, functions of thevehicle, and/or applications of the vehicle, with a selected level ofknowledge of the changes by the controlling device, application, orcontroller, including without any knowledge of the changes. Embodimentsherein including allowing for active monitoring, service eventexecution, and/or test execution of devices, end points, controller,flows, device groups, functions of the vehicle, applications of thevehicle, or the like, which may be on any network of the vehicle and/ordistributed across more than one network of the vehicle, from devices,applications, or controllers that may communicate with any network ofthe system. Additionally or alternatively, embodiments herein maysupport active monitoring, service event execution, and/or testexecution of devices after changes to the controlled devices, endpoints, controllers, flows, device groups, functions of the vehicle,and/or applications of the vehicle, with a selected level of knowledgeof the changes by the controlling device, application, or controller,including without any knowledge of the changes.

Embodiments herein support mixed and/or scalable network topologies,including mixed networks, and/or multiple instances of a given networktype (e.g., separated and/or partially separated networks). The numberand arrangement of networks may be provided to support any aspect of thevehicle design, operation, and life cycle management, including atleast: allowance for a mix of legacy devices with newer devices;separation of network physical location and function; changes to thevehicle during service, maintenance, upgrades, and/or model changes;and/or reduction and/or compartmentalization of design efforts and/orintegration efforts. Without limitation, embodiments herein support dualzone network architectures, and/or n-zone network architectures.

Embodiments herein support consolidation of controls that may otherwisebe distributed around the system, for example to reduce the number ofcontrollers and/or processing devices that must be installed,integrated, and/or have interfaces therebetween, to reduce physical riskto the network system, to reduce a cost of the network system, and/or toreduce a footprint of the network system (e.g., reducing an overallfootprint of the vehicle and/or allowing a shift of the footprint inwhole or part to another system of the vehicle). Embodiments hereinsupport data management and access in a mixed network vehicle, includingabstracting data providers from data consumers, implementing dataauthorization, security, and compartmentalization, reducing networktraffic, and managing capability differences between end points,devices, controllers, flows, device groups, networks, and the like.

Embodiments herein provide for configuration of mixed network controldevices, including interfaces to allow for configuration of networkmanagement, network control, and network monitoring applications.Embodiments herein provide for configuration of mixed network controlsub-components, including interfaces therefore, such as for devices thatinterface between networks, and facilitate gathering, encapsulation,and/or processing of communications from a first network forcommunication onto a second network. Embodiments herein provide forconfiguration of mixed network control devices and/or sub-componentsselectively utilizing an external tool (e.g., a service tool,manufacturing tool, diagnostic tool, consumer device, etc.) which may becoupled to the mixed network control device with a direct connection,wireless connection, cellular connection, or other communicativeconnection. In certain embodiments, configuration tools herein may beexternal tools, web applications, mobile applications, dedicated orproprietary applications, or combinations of these.

For the purposes of promoting an understanding of the principles of thedisclosure, reference will now be made to the embodiments illustrated inthe drawings and described in the following written specification. It isunderstood that no limitation to the scope of the disclosure is therebyintended. It is further understood that the present disclosure includesany alterations and modifications to the illustrated embodiments andincludes further applications of the principles disclosed herein aswould normally occur to one skilled in the art to which this disclosurepertains.

BRIEF DESCRIPTION OF THE FIGURES

FIG. 1 is a schematic diagram of an example system for regulatingnetworks on a vehicle according to certain embodiments of the presentdisclosure.

FIG. 2 is a schematic diagram of an example system for regulatingnetworks on a vehicle according to certain embodiments of the presentdisclosure.

FIG. 3 is a schematic diagram of an example system for regulatingnetworks on a vehicle according to certain embodiments of the presentdisclosure.

FIG. 4 is a schematic diagram of a converged network device (CND).

FIG. 5 is a schematic diagram of a converged network device (CND).

FIG. 6 is a schematic diagram of a converged network device (CND).

FIG. 7 is a schematic diagram of a converged network device (CND).

FIG. 8 is a schematic diagram of a converged network device (CND).

FIG. 9 is a schematic diagram of a converged network device (CND).

FIG. 10 is a schematic diagram of a configurable ethernet switch.

FIG. 11 is a schematic diagram of a configurable edge gateway.

FIG. 12 is a schematic diagram of an example system for regulatingnetworks on a vehicle according to certain embodiments of the presentdisclosure.

FIG. 13 is a schematic diagram of an example system for regulatingnetworks on a vehicle according to certain embodiments of the presentdisclosure.

FIG. 14 is a schematic diagram of an example system for regulatingnetworks on a vehicle according to certain embodiments of the presentdisclosure.

FIG. 15 is a schematic diagram of an example system for regulatingnetworks on a vehicle according to certain embodiments of the presentdisclosure.

FIG. 16 depicts illustrative operations to process a message.

FIG. 17 depicts illustrative operations to down-sample a message.

FIG. 18 depicts illustrative operations to up-sample a message.

FIG. 19 is a schematic diagram of a system for regulating networks on avehicle according to certain embodiments of the present disclosure.

FIG. 20 is a schematic diagram depicting network zones in distributedrisk profiles.

FIG. 21 is a schematic diagram of a system for regulating networks on avehicle according to certain embodiments of the present disclosure.

FIG. 22 is a schematic diagram depicted a distributed CND with a networkredundancy circuit.

FIG. 23 is a schematic diagram of a system for regulating networks on avehicle according to certain embodiments of the present disclosure.

FIG. 24 is a schematic flow diagram depicting an example procedure foradjusting inter-network communication regulation.

FIG. 25 is a schematic flow diagram depicting an example procedure forencapsulating communications.

FIG. 26 is a schematic flow diagram depicting an example procedure forprocessing communications.

FIG. 27 is a schematic diagram of a system for providing a data service.

FIG. 28 is a schematic diagram of a system for regulating networks on avehicle.

FIG. 29 is a schematic diagram of a system for regulating networks on avehicle.

FIG. 30 is a schematic diagram of a system for regulating networks on avehicle.

FIG. 31 is a schematic diagram of a system for regulating networks on avehicle.

FIG. 32 is a schematic diagram depicting example network regulatingcomponents.

FIG. 33 is a schematic diagram depicting example network regulatingcomponents.

FIG. 34 is a schematic diagram depicting example network regulatingcomponents.

FIG. 35 is a schematic flow diagram of a procedure for publishing a dataservice.

FIG. 36 is a schematic flow diagram of a procedure for encoding a firstnetwork data set into a second network data set.

FIG. 37 is a schematic flow diagram of a procedure for providing networkstatus data.

FIG. 38 is a schematic flow diagram of a procedure for mirroring a port.

FIG. 39 is a schematic flow diagram of a procedure for encoding a firstnetwork data set.

FIG. 40 is a schematic flow diagram of a procedure for executing anactive test procedure.

FIG. 41 is a schematic flow diagram of a procedure for regulating anetwork of a vehicle.

FIG. 42 is a schematic flow diagram of a procedure for regulatinginter-network communications of a vehicle.

FIG. 43 is a schematic flow diagram of a procedure for encoding anethernet based data set.

FIG. 44 is a schematic flow diagram of a procedure for providing networkstatus data.

FIG. 45 is a schematic flow diagram of a procedure for performing acontrol operation.

FIG. 46 is a schematic flow diagram of a procedure for providing aneternal message value.

FIG. 47 is a schematic diagram of a CND.

FIG. 48 is a schematic diagram of an end point of a network responsiveto an actuator command value.

FIG. 49 is a schematic diagram of a system for regulating networkcommunications of a vehicle.

FIG. 50 is a schematic flow diagram of a procedure for commanding anactuator.

FIG. 51 is a schematic flow diagram of a procedure for commanding anactuator.

FIG. 52 is a schematic flow diagram of a procedure for commanding anactuator.

FIG. 53 is a schematic flow diagram of a procedure for transmittingcollected data to an external device.

FIG. 54 is a schematic flow diagram of a procedure for performing anactive diagnostic.

FIG. 55 is a schematic flow diagram of a procedure for commanding anactuator.

FIG. 56 is a schematic diagram of a system for regulating networkcommunications of a vehicle.

FIG. 57 is a schematic flow diagram of a procedure for regulatingnetwork communications of a vehicle.

FIG. 58 is a schematic flow diagram of a procedure for regulatingnetwork communications of a vehicle.

FIG. 59 is a schematic flow diagram of a procedure for regulatingnetwork communications of a vehicle.

FIG. 60 is a schematic diagram of a system for regulating networkcommunications of a vehicle using a scheduled policy.

FIG. 61 is a schematic diagram of a system for providing visualizationdata of a network of a vehicle.

FIG. 62 is a schematic, illustrative, example of a local DNS table.

FIG. 63 is a schematic, illustrative, example of vehicle communicationsdata.

FIG. 64 is a schematic, illustrative, example of visualization data.

FIG. 65 is a schematic, illustrative, example of visualization data.

FIG. 66 is a schematic, illustrative, example of visualization data.

FIG. 67 is a schematic, illustrative, example of visualization data.

FIG. 68 is a schematic, illustrative, example of visualization data.

FIG. 69 is a schematic diagram of a visualization management controller.

FIG. 70 is a schematic flow diagram of a procedure for providingvisualization data.

FIG. 71 is a schematic flow diagram of a procedure for providingvisualization data.

FIG. 72 is a schematic diagram of a system for regulating networkcommunications of a vehicle.

FIG. 73 is a schematic, illustrative, example of a policy.

FIG. 74 is a schematic, illustrative, example of a policy.

FIG. 75 is a schematic, illustrative, example of a policy.

FIG. 76 is a schematic flow diagram of a procedure for regulatingnetwork communications of a vehicle.

FIG. 77 is a schematic flow diagram of a procedure for providingvisualization data.

FIG. 78 is a schematic flow diagram of a procedure for updating apolicy.

FIG. 79 is a schematic diagram of a system for regulating networkcommunications of a vehicle.

FIG. 80 is a schematic, illustrative, example of a policy.

FIG. 81 is a schematic flow diagram of a procedure for regulatingnetwork communications of a vehicle.

DETAILED DESCRIPTION

Referencing FIG. 1, an example system schematically depicts aspects ofembodiments of the present disclosure. The example system includes anapplication 102 (e.g., a vehicle) having a first network 104 and asecond network 106 thereon. A network, as utilized herein, should beunderstood broadly, and may include one or more aspects such as: thehardware implementation (e.g., wires and wiring configurations,applicable standards such as connectors, insulation, shielding, wirerequirements such as gauging, twisting, coaxial arrangements, etc.),implementations of any layer (e.g., from the ISO 7 layer model, such as:application layer, presentation layer, session layer, transport layer,network layer, data link layer, and/or physical layer; although a givennetwork may have fewer layers, and/or layers organized in a distinctmanner); and/or may be wired or wireless in whole or part. Withoutlimitation to any aspect of the present disclosure, example andnon-limiting networks include a Controller Area Network (CAN), a MediaOriented Systems Transport (MOST) network, a Local Interconnect Network(LIN), a FlexRay network, a Time-Triggered Protocol (TTP) network, aLow-Voltage Differential Signaling (LVDS) network, and/or an Ethernetimplemented network. In certain embodiments, one or more networks may bean electrical signal zone (e.g., a device providing data and/orreceiving commands as an electrical signal, such as a voltage value, afrequency value, and indicated resistance value, or the like), such as asensor or actuator electrically coupled to an interpreting device thatis capable to receive information from, and/or pass information orcommands to, one or more electrical devices on the electrical signalzone.

An example system includes the first network 104 being of a differenttype than the second network 106. As utilized herein, two networkshaving different types should be understood broadly, and includesnetworks having different protocols, at least one layer distinct fromeach other (e.g., having a distinct application layer, presentationlayer, etc.), two networks that are not operationally compatible (e.g.,a device coupled to one of the networks will not function on the secondnetwork without changes to connections, communications, or otheraspects), and/or two networks that are not message compatible (e.g.,messages configured for a first one of the networks could not bedirectly placed on the second one of the networks, due to a distinctionsuch as addressing, frame construction, message logic compatibility,etc.). An example system includes the first network 104 being anEthernet implemented network, and the second network 106 of a differenttype, such as a CAN network and/or a LIN network.

The example system further includes a converged network device (CND) 108interposed between the first network 104 and the second network 106, andstructured to facilitate communications between the first network 104and the second network 106. The CND 108 interposed between the networks104, 106 includes embodiments wherein the CND 108 passes communicationsbetween the networks 104, 106, for example receiving a communicationfrom the first network 104, translating the communication for the secondnetwork 106 (e.g., encapsulating all or a portion of the communicationinto a message for the second network 106; converting aspects of thecommunication such as device addresses, bit depths for data, and/or unitvalues for data; and/or adding or removing aspects of the communicationsuch as priority information, message delivery requests or requirements,industry standard information such as message identifiers, etc.). Incertain embodiments, the CND 108 does not physically passcommunications, or just passes a portion of the communications, but mayregulate, manage, provide permissions, suppress messages, or otherwisecontrol other devices (e.g., switches, routers, gateways, repeaters, orthe like) that perform operations to pass communications between thenetworks. Accordingly, the CND 108 interposed between the networks 104,106 may, in certain embodiments, be physically positioned between thenetworks 104, 106, where communications passing between the networks104, 106 are physically received by a component of the CND 108. Incertain embodiments, the CND 108 interposed between the networks 104,106 may have visibility to communications on the networks 104, 106, andcontrol devices to regulate the passing of messages between thenetworks. In certain embodiments, the CND 108 interposed between thenetworks 104, 106 may have visibility of end points on the networks 104,106, and control devices to regulate the passing of messages between theend points of each network 104, 106.

One of skill in the art, having the benefit of the present disclosure,can readily arrange a CND 108 according to one of these interpositionschemes, and/or according to a combination of more than one of theseinterposition schemes, having information ordinarily available whencontemplating a particular system. Certain considerations when designingan interposition scheme for a CND 108 for a given system include,without limitation, include: the number and type of networks on thevehicle; the capabilities of the individual networks (e.g., throughput,bandwidth, address availability, broadcast/unicast/multi-castavailability and desirability of each network and/or end points on anetwork, requirements and/or availability of acknowledgment for eachnetwork and/or end points, and/or requirements and/or availability ofencryption for each network and/or end points); the availability,position, and/or control over network implementing controllers (e.g.,presence and ownership of switching devices; access to instructions,such as firmware or buffers, for available devices; and/or theconnectivity of available devices to the one or more networks, such aswhether the devices are arranged to implement desired message passingbetween networks, desired redundancy, and/or desired failure moderesponse); capability of network implementing controllers (e.g., buffersizing and availability, message rate capacity, processing capacity);hardware cost considerations for adding CND-specific components to thesystem; hardware cost considerations for providing capability for CNDoperations in other components of the system; integration costconsiderations and system capability to implement additionalCND-specific components and/or adding capability for CND operations inother components of the system); the number, type, and/or messagethroughput of end points that utilize cross-network communications; theexpected change of any one or more of these aspects over the life of thevehicle (e.g., due to service events, upgrades, and/or campaign eventssuch as product recall events related to the vehicle); and/or theexpected change of any one or more of these aspects over a life cycle ofa related group of vehicles (e.g., a related fleet of vehicles; modelyear of vehicles; and/or a group of model years relevant to the system,such as vehicles expected to have a similar network infrastructure, withvariance to the distribution of devices, changes to the network, or thelike).

In the example of FIG. 1, a first external device 110 is depicted ascommunicatively coupled to the application 102. The first externaldevice 110 is directly coupled to the application 102, which may includea directed wired connection (e.g., to a service port, OBD port, or otheravailable connection) and/or a wireless connection (e.g., a WiFiconnection such as an IEEE 801.11 compatible connection, and/or aBluetooth connection). The first external device 110 may connect to aspecific network (e.g., the first network 104 or the second network106), and/or may connect to another device (e.g., the CND 108 and/or adevice regulated by the CND 108) that manages communications with theexternal device 110 directly. Whether the external device 110 is coupledto a network 104, 106 or another device such as the CND 108, in certainembodiments the CND 108 is capable to manage communications such thatthe external device 110 receives only authorized communications, andfurther to manage communications such that the external device 110 mayrequest communications from an end point on any network 104, 106 andnevertheless receive the requested information. In certain embodiments,the first external device 110 may be a service tool, original equipmentmanufacturer's (OEM's) tool, a manufacturer's tool, a body builder'stool, and/or an application (e.g., an application communicating througha computing device such as a laptop, desktop, mobile device, and/ormobile phone; e.g., an application operated by an owner, servicerpersonnel, fleet manager, or the like).

In the example of FIG. 1, a second external device 114 is depicted incommunication with the application 102 and/or the first external device110 through a cloud connection 112. The cloud connection 112 may be aconnection of any type, including a mobile connection (e.g., a modem onthe application 102 connecting using cellular data or another dataservice), an internet connection, a wide area network (WAN), and/orcombinations of these. The cloud connection 112 may access theapplication 102 through a transceiver, which may form a part of the CND108 and/or be regulated, at least in part, by the CND 108. In certainembodiments, an application 102 may have more than one transceiver,where one or more, or all, of the transceivers are regulated, at leastin part, by the CND 108. In certain embodiments, the CND 108 mayregulate certain vehicle communications (e.g., from certain networks,end points, devices, types of data, flows, and/or applications on thevehicle), but not other communications.

An end point, as used herein, should be understood broadly. An end pointis an organizing concept for access to a network 104, 106 of thevehicle, and may include a specific device (e.g., an engine controller,a transmission controller, a door controller, an infotainment system,etc.), a group of devices having a single network access (e.g., multipledevices communicating together through a single network access point,where the network 104, 106 and/or the CND 108 may have visibility to theindividual devices, or may only have visibility to the communicationsfrom the end point as a group). For example, a door controller (notshown) may be an end point for one of the networks 104, 106, withcommunications for underlying devices (e.g., door position sensor, doorlock actuator and position, window actuator and position, etc.) passingto the network 104, 106 through the door controller end point, where theCND 108 may have visibility to the underlying devices (e.g., a messageindicating door position, that includes identifiers that the doorposition sensor is sending the message), or may have visibility only tothe door controller end point (e.g., the message indicating the doorposition is known to be provided by the door controller, but the CND 108does not know which underlying device may have sent the message). One ofskill in the art, having the benefit of the present disclosure andinformation ordinarily available about a contemplated system, canreadily determine which devices in the system are end points for eachnetwork 104, 106. Certain considerations for determining end pointarrangements include, without limitation: the availability of hardwareports on the network(s); the distribution of vehicle controllers; themessages that are to be passed between vehicle controllers; theregulating options (e.g., message rates, priorities, data collection,message configuration, identity information of components, addressingmanagement between networks and with external devices, etc.) as setforth in the present disclosure that are to be available for a given endpoint; the desired granularity of data control (e.g., permissions forspecific devices to provide or request information; permissions forapplications either on-vehicle or off-vehicle to provide or requestinformation; security authorization and type, such as per-user,per-entity, per-device, per-application, per-flow, etc.); and/orredundancy options that are to be available for the given system (e.g.,redundancy of network communications capability, redundancy of controloperations and related devices, and/or redundancy of CND operationswhere CND components are distributed in more than one location of thevehicle).

An application, as utilized herein, should be understood broadly. Anexample application includes a group of related vehicle functions oroperations, for example speed control (e.g., of the vehicle, or asub-component of the vehicle such as an engine or a driveline),anti-lock brake system (ABS) operations, an advanced driver-assistancesystem (ADAS), performance control (e.g., achieving a torque request,speed request, or other performance request from an operator), or otherfunction of the vehicle. An example application includes a group ofrelated functions apart from the vehicle, such as an application tosupport geolocation and/or navigation, to request and/or process serviceinformation about the vehicle, and/or a third-party applicationinteracting with the operator (e.g., to find a nearest hotel, selectedevent, etc.). Applications may be implemented by the vehiclemanufacturer, a supplier, an original equipment manufacturer, a bodybuilder, a third party, the operator, service personnel, or the like.Applications, as used herein, provide an organizing concept that may beutilized to relate certain data, certain end points, and/or relatedfunctions of the vehicle. In certain embodiments, the CND 108 canutilize an application to identify a data source, a data destination,permissions available for the application, priority information relatedto the application, or the like, to implement certain data regulatingoperations herein.

A flow, as utilized herein, should be understood broadly. An exampleflow includes a related group of data (e.g., speed data, temperaturedata, audio-visual data, navigation data, etc.), a related group offunctions (e.g., among vehicle functions, extra-vehicle functions suchas service operations and/or data collection, aggregations betweenrelated vehicles, and/or combinations of these that are related for aparticular system), a related group of devices (e.g., door actuators),and/or a related group of applications. Flows, as used herein, providean organizing concept that may be utilized to relate certain data,certain end points, certain applications, and/or related functions ofthe vehicle or apart from the vehicle. In certain embodiments, the CND108 can utilize a flow to identify a data source, a data destination,permissions available for the flow, priority information related to theflow, or the like, to implement certain data regulating operations here.In certain embodiments, the utilization of the flow allows the CND 108to perform separate operations that may involve the same end points tosupport the desired network management. For example, a vehicle speedmanagement application may have a high priority, and a speedometer endpoint may be associated with the vehicle speed management application.In the example, if the vehicle speed is being communicated to supportthe vehicle speed management application, then the CND 108 applies ahigh priority to the vehicle speed message. However, if the vehiclespeed is being communicated to support a trip planning flow (e.g., wherea trip planning flow is present and does not have a high priority), theCND 108 may apply a lower priority to the vehicle speed message. In afurther example, a failure of a vehicle controller, portion of anetwork, or other off-nominal condition may result in the migration ofthe vehicle speed management application to another controller in thesystem, whereby the vehicle speed message is being communicated (e.g.,where the backup controller is on another network) to support thevehicle speed management application, and the CND 108 may apply a higherpriority to the vehicle speed message. The utilization of flows andapplications to organize the components of the system allows for thesame or similar information to be regulated by the CND 108 in adifferential manner to support various functions, allowing forimprovements in the performance and security of network regulationoperations (e.g., reducing unnecessary cross-network traffic, andproviding information only as needed), and supports additionalfunctionality relative to previously known systems, such as redundancysupport, distributed control, and granular cross-network messaging.

A service group, as utilized herein, should be understood broadly. Anexample service group includes a related group of applications for thevehicle. The related group of applications may be entirely positioned onthe vehicle (e.g., one or more vehicle systems, functions, or otherapplications of the vehicle), and/or may include aspects that arepositioned on external devices (e.g., with supporting processing, datacollection or storage, externally sourced data used by the servicegroup, etc.) which may be a web application, web tool, cloudapplication, service application, or the like. In certain embodiments,any group of local communicating devices may be logically related as aservice group. The utilization of service groups to organize thecomponents and/or applications of the system allows for the same orsimilar information to be regulated by the CND 108 in a differentialmanner to support various functions, allowing for improvements in theperformance and security of network regulation operations (e.g.,reducing unnecessary cross-network traffic, providing information onlyas needed, and/or regulating communications with external devices), andsupports additional functionality relative to previously known systems,such as redundancy support, distributed control, and granularcross-network messaging.

Regulated components, as utilized herein, and without limitation to anyother aspect of the present disclosure, include any components of asystem that are regulated with respect to communications, including datacollection, subscriptions, data requests, access to external devicesand/or addresses, access to network zones, access to end points,utilization of communication resources (e.g., network zone bandwidth,external communication portals, total data limits or quantities, etc.).Regulated components include, without limitation, one or more of: endpoints, flows, applications, controllers, service groups, interfacecircuits, network zones, external communication portals, externaldevices, source addresses, destination addresses, vehicle functions,entities associated with any of these, users associated with any ofthese, and/or user roles associated with any of these.

Referencing FIG. 2, an example system includes a vehicle 202 having afirst network 104, a second network 106, and a CND 108 interposedbetween the networks 104, 106. The example system depicts the vehicle202 communicatively coupled to an external device 110, similar to thedepiction of FIG. 1, and/or communicatively coupled to a second externaldevice 114. The example of FIG. 2 depicts another external device 204communicatively coupled to the vehicle 202, through the cloud connection112 in the example. The third external device 204 is depictedschematically as a lap top, for example as operated by a fleet servicemanager, owner, and/or vehicle representative (e.g., a warrantyadministrator). The example of FIG. 2 is an illustrative depiction toshow additional context options and a specific application as a vehicle,but is otherwise similar to the system of FIG. 1.

Referencing FIG. 3, an example embodiment including a vehicle 202 isschematically depicted, illustrating certain further details that may bepresent in certain embodiments. The example system includes the vehicle202 having a first network 104 and a second network, and a CND 108interposed between the first network 104 and the second network. In theexample of FIG. 3, the second network is an Ethernet network withdevices (e.g., an interactive dashboard 302, a door actuator 310, and atransmission controller 320) coupled to an Ethernet switch 312. In theexample of FIG. 3, a third network 318 is shown, with a fuel tank sensor306 coupled to the CND 108. In the example, the third network 318 may beof the same type as one of the other networks, for example segregatedfrom the other networks to improve the cost of installation, riskmanagement, or for other considerations, and/or the third network may beof a different type to support devices—for example a sensor operating ona LIN network. The third network 318 may communicate with the CEG 314,the Ethernet switch 312, or another device (not shown) of the CND 108.

The example of FIG. 3 includes a first device 308 on the first network104 (e.g., a controller for a prime mover, in the example of FIG. 3),and a number of devices (e.g., an interactive dashboard 302, a fuel tanksensor 306, and a door actuator 310, in the example of FIG. 3) on thesecond network. The system includes one of the devices 302, 310, 320 onthe second network communicating to the first device 308 via the CND108. For example, the door actuator 310 may lock the door when thevehicle 202 moves, pulling the vehicle movement information (e.g.,engine speed, gear position, vehicle speed, and/or a state parametersuch as a “VEHICLE MOVING” Boolean value, bit mask, or the like) fromthe first device 308.

The arrangement of FIG. 3 is a non-limiting example. Additionally oralternatively, a given device (e.g., the prime mover 308) may appear asa single end point or as multiple end points, for example the controllerof the prime mover 308 may provide numerous parameters to the firstnetwork 104, which may each be provided with an identifier and operateas separate end points (e.g., engine temperature from an enginetemperature sensor), and/or may include parameters provided by the primemover 308 controller as such (e.g., engine temperature from the enginecontroller).

To illustrate an example of FIG. 3, the first network 104 may be a CANbus network, where the desired data (e.g., a vehicle movement indicator)is provided according to considerations for the CAN network, and as aCAN message. The door actuator 310 is provided on the second network,for example an Ethernet network where the door actuator 310 is on a portof the second network. The port for the door actuator 310 may be aphysical port (e.g., a port of an Ethernet switch 312 dedicated for thedoor actuator 310) or a virtual port (e.g., an address location for thesecond network, which may be on a shared physical port with one or moreother devices). In the example of FIG. 3, the door actuator 310 cannotreceive the CAN message indicating vehicle movement, and the CND 108interprets a request from the door actuator 310 for the vehicle movementindication, retrieves the message from the first network 104, and sendsthe message to the door actuator 310 over the second network.

The operations performed to send the message may vary with theapplication. For example, the CND 108 may publish to devices on thesecond network that certain parameters are available from the firstnetwork 104 (and/or third network 318), and provide selected parametersto devices directly (e.g., providing the vehicle movement indicator torequesting devices), or publish data values representing parameters thatare available to subscribing devices for those parameters (e.g.,utilizing a broker—not shown—to make subscribed parameters available).In certain embodiments, the CND 108 may limit publication of parametersavailable to devices, end points, applications, and/or flows that areauthorized to see those parameters are available. Stated differently,different devices on the second network may see a different list ofparameters available, depending upon the authorization of those devicesand/or applications or flows associated with those devices. In certainembodiments, the CND 108 may limit provision of the parameters todevices, end points, applications, and/or flows that are authorized toreceive those parameters—for example by denying a subscription requestfor a parameter and/or suppressing the sending of a parameter to anunauthorized device despite the subscription. Accordingly, in certainembodiments, a device may be able to see that a parameter is available(e.g., in a published list of available parameters), but be unable toreceive data values of the parameter. In certain embodiments, a devicemay be limited to seeing available parameters that the device isauthorized to receive.

In certain embodiments, a device may have only limited availability toreceive a parameter, for example the CND 108 may limit the rate of adata value to support reduced network utilization, data securityconsiderations (e.g., limiting the accuracy, resolution, and/or datarate of sensitive parameters such as vehicle position), and/or tosupport proprietary considerations (e.g., limiting the accuracy,resolution, and/or data rate of parameters that may relate to aproprietary control operation, for example to limit the ability for anapplication to reverse engineer or otherwise determine how the controloperation functions).

In certain embodiments, the CND 108 determines which parameters topublish, to provide, and the conditions to provide them, based uponstored data defining permissions and/or capabilities of devices, endpoints, applications, flows, and the like. In certain embodiments, theCND 108 further accesses stored data defining processing or adjustmentoperations to the data, for example encapsulation operations (e.g., topass CAN messages to an Ethernet network), unit conversions, time stampdefinitions, and the like. In certain embodiments, the CND 108determines the authorization for applications and/or flows that are onvehicle, off vehicle (e.g., operating on an external device such as 110,114, 204), or combined on and off vehicle. In certain embodiments, theCND 108 may support prioritization of data flow, including the rate atwhich devices provide information or receive information, based upon aprioritization of the related device, end point, application, flow, orother parameter. In certain embodiment, the CND 108 may supportdifferential prioritization based upon the vehicle status or operatingcondition, for example using a first priority scheme during startupoperations, a second priority scheme during run-time operations, a thirdpriority scheme when the vehicle is moving, etc. In certain embodiments,the CND 108 may be responsive to any defined vehicle condition, such ascharging, regenerating, aftertreatment operations, control regimes(e.g., cruise versus operator control), emergency conditions, faultconditions, a service condition, or the like.

The example CND 108 of FIG. 3 includes a first device 314 thatcommunicates with the first network 104. An example first device 314includes a configurable edge gateway (CEG), that reads communicationsfrom the first network 104, and provides them to the second network 106.In certain embodiments, the first device 314 translates thecommunications for the second network, for example encapsulating thecommunication, a portion of the frame of the communication, and/or apayload of the communication, into a message for the second network. Incertain embodiments, the first device 314 is capable to requestcommunications from devices on the first network 104, for examplerequesting a parameter that is available but is not currently beingcommunicated onto the first network 104. In certain embodiments, thefirst device 314 is not a part of the CND 108, but is controlled by theCND 108, for example by responding to command from the CND 108,accessing stored data that is written, in whole or part, by the CND 108,or through other operations as provided throughout the presentdisclosure.

The example CND 18 of FIG. 3 includes a second device 312 thatcommunicates with the second network. An example second device 312includes an Ethernet switch, which may be configurable, that readscommunications from the second network. In certain embodiments, thesecond device 312 receive messages from the first network 104 throughthe first device 314, for example receiving messages in a format that iscommunicable on the second network. An example first device 314 includesa CEG that communicates to the Ethernet switch through a port on theEthernet switch that is provided for messages from the first device 314.Accordingly, FIG. 3 provides an illustration of a second device 310 on asecond network, that communicates with the first device 308 via the CND108.

An example system includes an external device 110, 114, 204 thatcommunicates with the CND 108. In the example of FIG. 3, the externaldevice 110, 114, 204 may communicate through a transceiver 304, and/orvia direct access to a network of the vehicle 202 (e.g., using a serviceport, OBD port, WiFi, Bluetooth, etc.). The external device isstructured to adjust a configuration of the CND 108—for example bychanging the stored data that provides for published available data,associated permissions, defined applications, defined flows, defined endpoints, defined devices, and the like. In certain embodiments, theexternal device has an associated permission value, and the CND 108permits changes according to the associated permission value, forexample blocking adjustments to changes associated with certainnetworks, devices, end points, applications, flows, or the like.

An example system includes the first network as a bus network, which mayfurther be a CAN bus network. An example system includes the secondnetwork as an Ethernet network, which may have any selected topologysuch a data bus architecture. In certain embodiments, the Ethernetnetwork may have a data bus architecture as a hardware topology, butoperate in a distinct manner logically (e.g., as a switched network).

Referencing FIG. 4, an example system includes a CND 108 having a firstnetwork gateway device 402 and a second network gateway device 404. Inthe example of FIG. 4, the first network gateway device 402 is a CEGthat accesses one or more CAN based networks 406, each having one ormore end points 408—for example devices coupled to the CAN network 406that provide communications to, and/or receive communications from, therespective CAN network 406. The example of FIG. 4 depicts two CANnetworks 406, which may be arranged for convenience of integration(e.g., to divide components of the vehicle logically by function, byposition in the vehicle, and/or any other arrangement such as a relatedgroup of components communicating on a common CAN network 406). In theexample, the first network gateway device 402 communicates with both CANnetworks 406, although the CND 108 may include, and/or may be configuredto regulate, more than one CEG, for example having one CEG accessingeach CAN network 406, and/or each CEG accessing a subset of the CANnetworks 406 on the vehicle. The example of FIG. 4 depicts bus networks406, and the networks 406 are described as CAN networks for purposes ofillustration, but the networks 406 may be of any type as describedthroughout the present disclosure. The end points 408 may be any type ofend point capable to communicate with the network 406, such as acontroller, smart sensor or actuator, or other device capable to providecommunications to the network 406, and/or receive communications fromthe network 406.

The example of FIG. 4 describes the CND 108 as including the networkgateway devices 402, 404, but the CND 108 may be separate from one ormore of the network gateway devices 402, 404, and may configureoperations of the network gateway devices 402, 404, for example byadjusting stored data thereon, adjusting stored data accessible to thedevices 402, 404, providing commands thereto, and/or performing anyother operations as set forth throughout the present disclosure.

In the example of FIG. 4, the second network gateway device 404 is anEthernet switch that accesses an Ethernet based network 410, depictedschematically as a number of end points 412 communicating with a numberof ports 414 of the Ethernet switch 404. The ports 414 are depictedschematically, and may be logical ports, hardware ports, or combinationsof these. The physical topology of the Ethernet network 410 may be a busarrangement, a hub arrangement, a star arrangement, or any other type ofnetwork topology, and which may be distinct from the logical topology ofthe Ethernet network 410. The second network gateway device 404 isdepicted as having a network interface 416, which may include thephysical port connection(s). In certain embodiments, the second networkgateway device 404 is a configurable Ethernet switch, which may includea processor, computer readable storage (e.g., to store instructions,configuration information, buffering for data communication and/orcollection operations, and the like). These aspects are not shown forclarity of the depiction and the present description, but they may bepresent on the second network gateway device 404, within a same housingas the second network gateway device 404, on a separate board (e.g.,mounted on a separate printed circuit board) from the network interface416 and/or from the remainder of the second network gateway device 404,positioned on another device in the system and in communication with thesecond network gateway device 4040 (e.g., on the first network gatewaydevice 404, on a vehicle controller, and/or on another controller in thesystem), and/or distributed across a combination of these locations.

In the example of FIG. 4, the first network gateway device 404 includesone or more network interface(s) 418 (and/or network interface circuit)that communicatively couple the first network gateway device 404 to thenetwork(s) 406, and a translation circuit 420 that configures messagesfrom the Ethernet network 410 for communication to the network(s) 406,and/or that configures messages from the network(s) 406 forcommunication to the Ethernet network 410. Additionally oralternatively, the translation circuit 420 configures messages forpassage from one of the network(s) 406 to another one of the network(s)406—for example where the networks 406 are of different types, utilizedifferent protocols, would otherwise have conflicting source ordestination information, and/or otherwise have distinct characteristicsthat are managed by the first network gateway device 404 to ensuremessage compatibility, successful mission operation of the vehicle,and/or to implement any other configuration operations as set forth inthe present disclosure. The translation circuit 420 is depictedschematically as a single device, but may be implemented as one or moredevices, for example with a number of translation circuit 420 componentseach implementing a type of configuration, interacting with a type ofnetwork 406, to distribute processing and/or memory operations of thetranslation circuit 420, or for any other reason according to theparticular system. In the example of FIG. 4, the first network gatewaydevice 404 provides messages to the Ethernet switch in response to acorresponding message on the CAN based network 406. In the example ofFIG. 4, the first network gateway device 404 provides the message to aport 414 of the Ethernet switch. In the example of FIG. 4, any messagesprovided from the networks 406 appear on the Ethernet network 410 as amessage on the port between the translation circuit 420 and the networkinterface 416, and is received from the Ethernet network 410 through theport between the translation circuit 420 and the network interface 416.The translation circuit 420 allows for configuration operations betweenmessages, such end points on each network 406, 410 can communicatetherebetween, as regulated by the CND 108.

The example of FIG. 4 further includes an on-board diagnostic (OBD)interface 422, which in the example communicates with a dedicated OBDport 424. The example of FIG. 4 is non-limiting for purposes ofillustration, and the OBD interface 422 may be associated with anynetwork, or more than one network (e.g., to support multiple OBD toolsthat may connect to the vehicle). An example embodiment includes the OBDinterface 422 associated with the second network gateway device 402, forexample where the OBD system is largely CAN based, allowing for reducedtraffic between the translation circuit 420 and the network interface416, as many of the OBD parameters are native to one or more of the CANnetworks 406. The OBD interface 422 may alternatively be present on theEthernet network 410, or present on more than one network 406, 410 ofthe system. Regardless of the location of the OBD interface 422 and thenetwork 406, 410 origination of OBD related data, OBD requests andinformation can be made available to the OBD port 424 (which may be aphysical connection, a wireless connection, or another externalconnection including a mobile data connection) via operations of the CND108 to authorize and provide cross-network communication from end pointsof any of the networks 406, 410. Additionally, the example of FIG. 4utilizes an OBD interface 422 as a non-limiting example, but any type ofspecial, dedicated, and/or proprietary interface may be provided in asimilar manner, with an interface and port that can make any data fromany end point on a network 406, 410 available, subject to configurableregulation by the CND 108.

An example system includes the CND 108 interposed between an electricalsensor and one of the networks 406, 410, and structured to provide asensed value on the network in response to an electrical response of theelectrical sensor. For example, one of the networks 406 may be anelectrical connection to the second network gateway device 402, with acorresponding end point 408 as the electrical sensor, and whereby thetranslation circuit 420 converts the electrical signal from the sensorto a communication for the respective network (e.g., network 410, oranother network 406). In the example, the translation circuit 420 mayperform processing operations on the electrical signal, such asanalog/digital (A/D) processing, determination of indicated bits,determination of an indicated value, de-bouncing of the signal,filtering of the signal, diagnostic bit detection (e.g., determinationof a fault, and conversion to a corresponding fault value; and/orconversion of predetermined voltage values to a corresponding faultvalue), saturation management (e.g., limiting outputs to predeterminedvalues), slew limitations (e.g., applying rate-of-change limits to theindicated value), and the like. Electrical signals from the sensor,where present, may be voltage values, frequency values, indicatedresistance values, or any other type of sensor electrical value as knownin the art.

In another example, a system includes the CND 108 interposed between anelectrical actuator and one of the networks 406, 410, and structured toprovide a command value from the network as a configured electricalresponse to the electrical actuator. For example, one of the networks406 may be an electrical connection to the second network gateway device402, with a corresponding end point 408 as the electrical actuator, andwhereby the translation circuit 420 converts the communication from therespective network (e.g., network 410, or another network 406) to anelectrical signal for the actuator. In the example, the translationcircuit 420 may perform processing operations on the electrical signal,such as digital-to-analog processing, determination from indicated bitsto corresponding values, diagnostic bit provision, saturationmanagement, slew limitations, and the like. Electrical signals to theactuator, where present, may be voltage values, frequency values,modulated values, or any other type of actuator electrical value asknown in the art. In certain embodiments, an electrical actuator mayadditionally have sensing values (e.g., position feedback,acknowledgment, etc.), and/or other feedback values (e.g., certainelectrical values indicating the actuator has a fault condition, isnon-responsive, is stuck, is saturated, etc.) which may be provided onthe same or a distinct electrical connection, and which may logically bepart of the same network 406 or a distinct network (e.g., actuation onone network 406, and feedback on a second network 406).

It can be seen that the embodiment of FIG. 4 provides for communicationbetween end points on distinct networks, without the end pointsrequiring knowledge about how communications to other end points are tobe performed, or where other end points are positioned. Withoutlimitation to any other aspect of the present disclosure, the embodimentof FIG. 4 provides the capability for operation of vehicle networks withdevices distributed across distinct networks, including networks of adifferent type. Additionally, the embodiment of FIG. 4 provides foroperation of the vehicle as devices move between networks, withoutlimitation to whether the device has changed communication capability.For example, a first device on a CAN network that is moved to theEthernet network can continue to function, with appropriateconfiguration of the CND 108, as messages that were utilized by thedevice from the CAN network can be moved to the Ethernet network andmade available to the device in the new position. In certainembodiments, the migrated device can continue to utilize previousalgorithms (e.g., the same local control)—for example computer readableinstructions specifically built for the specifics of the former CANmessages, including bit depth, resolution information, message rates,floating/fixed point data nature, and the like, with the CND 108configured to encapsulate the entire original CAN message into anEthernet message (e.g., a frame, a packet, and/or in a specifiedmanner), such that the migrated device can receive the former CANmessage as originally presented and utilized by that same local control.Accordingly, the embodiment of FIG. 4, and the principles set forth inrelation to FIG. 4, allow for changes in the end point device mixbetween networks, whether across a number of vehicles (e.g., changesthat occur over a course of design revisions, model years, or the like)or within a same vehicle (e.g., changes that occur during service,upgrades or changes to end points, upgrades, upfits, recallreplacements, etc.), with only an update to the CND 108 configuration tosupport the changes. In certain embodiments, the embodiment of FIG. 4and the principles set forth in relation to FIG. 4 allow for changes inthe end point device mix between networks without requiring an update tothe CND 108 configuration, for example where a range of end points arecontemplated to be available in more than one possible network locationand/or configuration, and where the CND 108 is configured to determinethe end point arrangement present on the vehicle and to utilize aselected configuration (e.g., from among two or more availableconfigurations) accordingly. Accordingly, the embodiment of FIG. 4, andthe principles set forth in relation to FIG. 4, further allow forchanges to the end point device mix between networks, at least within apredetermined range of end point devices and configurations, to supportvehicle operations without any changes to the vehicle, and even withonly intermittent or no communication with external devices forconfiguration of the CND 108.

Referencing FIG. 5, an example system includes a CND 108 regulatingcommunication between networks on a vehicle, where the networks may beseparated physically, logically (e.g., as virtual local area networks(VLANs), or other logical separation schemes), and/or two or more of thenetworks may be different types. The embodiment of FIG. 5 is generallyconsistent with the embodiment of FIG. 4, with some differences depictedto highlight certain aspects of the present disclosure. The example ofFIG. 5 includes additional interfaces 504, 506, which may be separatenetworks or network zones relative to the networks 406. The example ofFIG. 5 depicts a vehicle control device interface (VCDI) 508, which maybe an interface to a vehicle controller (e.g., engine controller,transmission controller, anti-lock brake system (ABS) controller,advanced driver-assistance system (ADAS) controller, door controller,battery controller, head unit, interactive dashboard, etc.) of any type,including a controller providing communications at the end point 504,and/or an electrical interface such as to a sensor, actuator, orcombined sensor and actuator. The example of FIG. 5 depicts anadditional interface 506 to an end point 502, which may be acommunicative device of any type as understood in the art or set forthherein. In the embodiment of FIG. 5, network interface circuits 418, 508are depicted between the end points 408, 502 and the translation circuit420, to allow for the translation circuit 420 to interface with numerousnetwork types that may be present on the vehicle. The interface circuits418, 508 may be positioned with the translation circuit 420, or locatedelsewhere and communicatively coupled to the associated network(s) andto the translation circuit 420. The example of FIG. 5 additionallydepicts networks 512, 514 that are communicatively coupled to the firstnetwork gateway device 404 through end points 412 on same network as thenetwork interface 416. In certain embodiments, the CND 108 does not haveor need specific knowledge about the networks 512, 514 or associated endpoints 516, 518, as communications to the networks 512, 514 are providedthrough the end points 412. However, the CND 108 is structured toprovide communications from networks in communication with the secondnetwork gateway device 402, such as networks 406, and/or networksinterfaced at end points 504, 506. Communications from the secondnetwork gateway device 402 may provide the requested information (e.g.,ambient temperature, door position, vehicle speed), for example as anencapsulated payload that provides the information, or as a nativemessage (e.g., a CAN message indicating ambient temperature, doorposition, vehicle speed; and/or a LIN message having associated sensorinformation). Accordingly, end points 516, 518 can send and receivetunneled messages with networks 406 (or other networks) in a sharedformat, or otherwise receive information from any network on thevehicle, subject to regulation by the CND 108.

Referencing FIG. 6, an example system includes a CND 108 regulatingcommunication between networks on a vehicle, where the networks may beseparated physically, logically (e.g., as virtual local area networks(VLANs), or other logical separation schemes), and/or two or more of thenetworks may be different types. The embodiment of FIG. 6 is generallyconsistent with the embodiment of FIG. 4, with some differences depictedto highlight certain aspects of the present disclosure. Withoutlimitation to any of the flexibility of arrangements depicted in FIG. 4,the example of FIG. 6 depicts the translation circuit 420 positioned inthe first network gateway device 404.

Without limitation to any other aspect of the present disclosure,co-location as depicted in FIG. 6, and as utilized herein, can indicatephysical co-location (e.g., the translation circuit 420 positionedwithin a shared housing with the first network gateway device 404,and/or on a same board with the first network gateway device 404) and/orlogical co-location (e.g., the grouping of operational responsibility ofimplementing hardware, such as connections, connectivity, operationalinstructions, stored data, data storage, and/or processing resources,etc.). The determination of a co-location scheme depends upon thepurpose of the co-location (e.g., sharing hardware resources, reducingexternal interfaces, simplifying and/or diversifying risk profiles ofthe co-located components and/or of other components in the systemrelated to the co-located components); the nature of the co-locatedcomponents (e.g., hardware implementations, processing and/or memoryresources related to the co-located components); the division ofownership of the co-located components (e.g., manufacturer, supplier,service party, vehicle owner, vehicle operator); operationalresponsibility of components and/or the vehicle (e.g., warranty,operational liability, service, insurance, uptime responsibility, etc.);and/or integration responsibility of components (e.g., installation,design, meeting a footprint requirement, tradeoffs between components,and/or ability to influence these). Accordingly, in certain embodiments,co-locating components may include one or more of: positioningcomponents within a shared housing or group of housings; positioningcomponents in a selected geometric proximity; positioning components ina selected logical arrangement (e.g., associating in a same flow orgroup of flows, associating in a same application or group ofapplications, providing operational constraints such as parameternaming, memory assignment, execution order, or the like); positioningcomponents in a selected risk profile arrangement (e.g., positioning ina same impact zone, a same temperature environment, a same NVHenvironment, a same EMI environment, subject to a same failure mode(e.g., electrical, logical, fault, physical impact, and/or dependency ona physical component such as a pump, cooling system, etc.)); on a sameboard; and/or within a shared memory location (e.g., computer readableinstructions positioned in a shared memory location, and/or executed bya same processor resource). In the example, NVH is the “noise,vibration, and harshness” environment, and EMI is the “electro-magneticinterference” environment. One of skill in the art, having the benefitof the present disclosure and information ordinarily available whencontemplating a particular system, can readily determine implementationsof components that are co-located as set forth in the presentdisclosure. It can be seen that components arranged in one or more ofthe described co-location schemes may be co-located for certainembodiments, or not co-located for other embodiments, and/or may beco-located for the purposes of certain operating conditions, but notco-located for the purposes of other operating conditions. Certainconsiderations to determine whether components are to be co-located, andthe selected co-location scheme for those components, include (withoutlimitation): the purpose of the co-location; operational costs ofresources (e.g., communications, processing resources, operationallimitations to the vehicle mission, operational impact to the vehiclemission such as cooling requirements, power consumption, and the like);capital costs of resources (e.g., computing power, networkinfrastructure, memory resources, individual component quality orcapability requirements, shielding requirements, data throughput whetherintra-vehicle or extra-vehicle, etc.); integration costs for components(e.g., footprint availability and cost, interface management, designflexibility and lock-down trajectory, and/or ability to trade-off and/oroptimize with other aspects of the system); and/or the ability todistribute costs to other interested parties related to the system(e.g., suppliers, manufacturers, customers, and/or service parties; andwhich may include the ability to distribute increased costs related toincreased capabilities, and/or to trade costs between interestedparties).

In the example of FIG. 6, the translation circuit 420 may providecommunications by, without limitation, populating and/or reading from ashared memory with the network interface 416, and/or by communicatingwith a port 414 (not shown).

Referencing FIG. 7, an example system includes a CND 108 regulatingcommunication between networks on a vehicle, where the networks may beseparated physically, logically (e.g., as virtual local area networks(VLANs), or other logical separation schemes), and/or two or more of thenetworks may be different types. The embodiment of FIG. 7 is generallyconsistent with the embodiment of FIG. 4, with some differences depictedto highlight certain aspects of the present disclosure. Withoutlimitation to any of the flexibility of arrangements depicted in FIG. 4,the example of FIG. 7 depicts the translation circuit 420 having a firstportion 702 co-located with the second network gateway device 402 and asecond portion 704 co-located with the first network gateway device 404.The portions 702, 704 of the translation circuit 420 may be separatedfor any reason, including at least separating translation operations bynetwork (e.g., which network 406 is being serviced), by predeterminedend points, by flows, by translation operation (e.g., processing offrame information, processing of payload information, managingcapability differences by down-sampling, up-sampling, buffering,providing communication commands, encapsulation of a message intoanother message format, etc.), and/or by direction of communication(e.g., direction between selected networks, between the gateway devices,between end points, between flows, or combinations of these).

Referencing FIG. 8, an example system includes a CND 108 regulatingcommunication between networks on a vehicle, where the networks may beseparated physically, logically (e.g., as virtual local area networks(VLANs), or other logical separation schemes), and/or two or more of thenetworks may be different types. The embodiment of FIG. 8 is generallyconsistent with the embodiment of FIG. 4, with some differences depictedto highlight certain aspects of the present disclosure. In the exampleof FIG. 8, the first network gateway device and the second networkgateway device are co-located, and omitted as being depicted as part ofthe CND 108. In certain embodiments, the CND 108 of FIG. 8 mayalternatively be a combined gateway device that is regulated by the CND108, rather than forming a part of the CND 108. In certain embodiments,one or more portions of the combined gateway device(s) may form a partof the CND 108, with other portions of the combined gateway device(s)regulated by the CND 108.

A policy, as utilized herein and without limitation to any other aspectof the present disclosure, includes a description of data to becollected, such as data parameters, collection rates, resolutioninformation, priority values (e.g., ordering data collection values forselection in response to off-nominal conditions where not all datacollection parameters can be serviced, etc.). In certain embodiments, apolicy further includes event information, which may be stipulated asparameter or quantitative based events (e.g., a given data value exceedsa threshold, etc.), and/or categorical events (e.g., a particular faultcode, operational condition or state, or vehicle location/jurisdictionoccurs). In certain embodiments, a policy further includes an eventresponse, such as data values to be captured in response to theoccurrence of the event, and/or other changes in the data collectionscheme such as increased or reduced data collection rates, changes incollected resolution, or the like. In certain embodiments, an eventresponse further includes a time frame associated with the eventoccurrence, for example a time period after the event occurrence toutilize the adjusted data collection scheme, and/or a time periodpreceding the event occurrence (e.g., utilizing a rolling buffer orother data collection operation, providing temporary information thatcan subsequently be captured if the event occurs). In certainembodiments, changes to the data collection scheme for an event caninclude multiple changes—for example changes over a period of time,further changes based upon the progression of the event (e.g., if theevent severity gets worse), and/or criteria to determine that an eventis cleared. In certain embodiments, changes to a data collection schememay be implemented based on event related clearance of the same oranother event, for example implementing a data collection change until anext shutdown event of the vehicle, until a service technician clearsthe event, for a selected number of shutdown events occurs, or the like.A policy may additionally or alternatively include parameters forperforming any regulating operations for any regulated components as setforth throughout the present disclosure.

The utilization of a policy herein may reference a partial policy, forexample the implied policy that would be implemented in response to asingle data collection scheme from a single user, wherein the fullpolicy is prepared, verified, and communicated to the vehicle after oneor more partial policies are aggregated. The utilization of a policyherein may reference an unverified policy, for example after a policyresponsive to a number of users is aggregated, but verificationoperations of the policy are not yet completed (e.g., before it isdetermined if the data collection implied by the policy can beperformed). The utilization of a policy herein may reference apreviously applied policy (e.g., a policy present on a vehicle before anupdated version of the policy is communicated to the vehicle and/orimplemented on the vehicle). The utilization of a policy herein mayreference an updated policy, for example a verified policy that ispending for communication to the vehicle and/or confirmed by the vehicle(e.g., from the CND 108).

Referencing FIG. 9, an example system includes a CND 108 regulatingcommunication between networks on a vehicle, where the networks may beseparated physically, logically (e.g., as virtual local area networks(VLANs), or other logical separation schemes), and/or two or more of thenetworks may be different types. The embodiment of FIG. 9 is generallyconsistent with the embodiment of FIG. 4, with some differences depictedto highlight certain aspects of the present disclosure. In the exampleof FIG. 9, the first network gateway device 404 and the second networkgateway device 402 are not co-located, and the CND 108 is depicted incommunication with the first network gateway device 404. The CND 108 maybe in communication with any one or more of the network gatewaydevice(s), and/or may be positioned at least partially on one or more ofthe network gateway device(s). Additionally or alternatively, the CND108 may regulate communication between the networks by accessing and/oradjusting a memory location (e.g., a policy, configuration instructions,a configuration table, or the like) available to one or more of thenetwork gateway device(s), where a relevant portion of the instructions(if any) may be passed to other network gateway device(s) if the CND 108does not communicate directly with those devices. In certain embodiments(not shown), the CND 108 may communicate to one or more of the networkgateway devices utilizing one or more of the networks, for example at aport 414 of the first network gateway device 404. In certainembodiments, the CND 108 may be positioned, at least partially, on oneor more of the network gateway devices, co-located with one or more ofthe network gateway devices, and/or included (at least partially) in acomponent of one or more of the network gateway devices (e.g., atranslation circuit and/or a network interface circuit).

Referencing FIG. 10, an example first network gateway device 404 isdepicted. In the example of FIG. 10, the first network gateway device404 is a configurable Ethernet Switch, including an Ethernet networkinterface 416 (or Ethernet network interface circuit) having a number ofports 414 for communication with an Ethernet network. The ports 414 maybe physical ports, logical ports, or a combination thereof.

Referencing FIG. 11, an example second network gateway device 402 isdepicted. In the example of FIG. 11, the second network gateway device402 is a configurable edge gateway (CEG), providing translation betweena secondary network 406 and a primary network interface (e.g., anEthernet network such as network 410). The utilization of secondary andprimary to reference networks merely indicates a logical arrangement ofnetworks, where interfaces to other networks than the primary arereferenced as edge interfaces (e.g., interfaced with an edge gateway).In certain embodiments, the primary network may have a higher capability(e.g., bandwidth, throughput, and/or resource dedication), a greaternumber of devices or end points thereon, a migration target network(e.g., over the life of a vehicle, a group of vehicles, a period ofmodel years, etc.) for end points over time, and/or a main entry networkfor external communications (e.g., over-the-air updates, configurationupdates, data collection, etc.), although a particular embodiment mayhave some, all, or none of these considerations present for a networkconsidered as a primary network. The example of FIG. 11 depicts anoptional OBD interface 422, which may be present elsewhere in thesystem, or not present in the system.

Referencing FIG. 12, a vehicle having a number of networks thereon,where communications between the networks are regulated by a CND 108, isschematically depicted. The arrangement of FIG. 12 is provided toillustrate certain aspects of the present disclosure, and is anon-limiting arrangement. The example of FIG. 12 includes end points1202, 1204 (e.g., one or more vehicle controllers) coupled to a firstnetwork 406, and a number of end points 1206, 1208, 1210, 1212 coupledto a second network (e.g., an Ethernet network, with a switch co-locatedwith the CND 108 and/or at least partially separate from the CND 108).In the example of FIG. 12, the controllers 1202, 1204, 1206, 1208, 1210,1212 are able to pass communications, as regulated by the CND 108,between disparate networks of the vehicle. In certain embodiments, agiven controller can be switched between networks, and communicationswith other controllers within the vehicle, and/or communicationsexternal to the vehicle, can be maintained, and further can bemaintained whether the related controllers (or external controllers,applications, or devices) have knowledge of the switch or not.

Referencing FIG. 13, a vehicle having a number of networks thereon,where communications between the networks are regulated by a CND 108, isschematically depicted. For purposes of illustration, the example ofFIG. 13 includes the same networks and set of controllers as the exampleof FIG. 12. In the example of FIG. 13, the controllers 1204, 1208, 1210,and 1212 have been co-located 1302, and the controller 1204 hasadditionally been moved from the first network 406 to the secondnetwork. The co-location 1302 of the controllers 1204, 1208, 1210, 1212can be any implementation, including consolidation of the controllersinto a lesser number of housings (e.g., 1-3 total housings instead of4), onto a lesser number of boards (e.g., 1-3 boards, instead of 4),and/or utilizing at least partially shared computing resources (e.g.,shared processing, shared memory, shared caches, and/or combinations ofthese). In certain embodiments, the utilization of the CND 108 allowsfor the arrangement of FIG. 13, including the consolidation of vehiclecontrollers, by providing for communication regulation, and maintainedconnectivity, with only a configuration update to the CND 108, and/orwith consolidation changes of vehicle controllers that fit withinavailable predetermined configurations of the CND 108 (and thereby canbe implemented without an update to the CND 108). Additionally, theconsolidation of controllers may provide a number of benefits, such asreduction in network costs, reduction in network traffic, selecteddistribution of risk (e.g., arrangement of controller positions and/ornetwork routing in a lower risk, or diversified risk, position; and/orreduction of risk to another system component utilizing the footprintgains and/or cost savings of the controller consolidation). In certainembodiments, the consolidation of controllers may enable deeper sharingof information between controllers (e.g., due to increased availablenetwork capacity, bypassing of network limitations with sharedcontrollers, and/or utilization of shared memory resources), which mayallow for more capable operations of the controllers, and/or operationspreviously unavailable because the shared information betweencontrollers was not as readily available. In certain embodiments, theCND 108 further enables the consolidation of controllers, by de-couplingthe controller locations from end point locations (not shown) that arerequired to be distributed (e.g., sensors and actuators that need to beplaced in certain locations to perform their function no longer need tobe located near the respective controller due to operations of the CND108, and/or CEG 402). In certain embodiments, the consolidation ofcontrollers allows for reduced costs and/or increased capability, forexample by reducing hardware costs for shared computing resources,enabling higher capability (e.g., processing power and/or memory)computing resources, or combinations of these. The operations of the CND108 thus allow for consolidation operations of vehicle controllers thatwere not previously available. In certain embodiments, the example ofFIG. 13 may be a consolidation of controllers relative to FIG. 12,and/or an illustration of an unrelated embodiment.

Referencing FIG. 14, a vehicle having a number of networks thereon,where communications between the networks are regulated by a CND 108, isschematically depicted. For purposes of illustration, the example ofFIG. 14 includes the same networks and a similar set of controllers asthe example of FIG. 12. In the example of FIG. 14, the co-located 1302controllers include a set of controllers 1402, 1404, 1406, and the CND108 depicted as a controller on the co-located 1302 controller. The CND108 may be positioned, at least in part, on one or more of theco-located controllers 1402, 1404, 1406, and/or may be separate asdepicted. In certain embodiments, the example of FIG. 14 may be afurther consolidation of controllers relative to FIG. 13, and/or anillustration of co-located 1302 controllers unrelated to the examples ofFIGS. 12 and 13.

Referencing FIG. 15, a vehicle having a number of networks thereon,where communications between the networks are regulated by a CND 1502,1504, is schematically depicted. For purposes of illustration, theexample of FIG. 15 utilizes two consolidated controllers 1302, 1506,each including a group of co-located vehicle controllers as set forththroughout the present disclosure. The example of FIG. 15 includes afirst CND 1502 (or CND portion) interposed between a first network 406and a second network (end points 412 directly coupled to the CND 1502and the consolidated controller 1506 directly coupled to the CND 1502),and a second CND 1502 (or CND portion) interposed between the firstnetwork 406 and a second network (end points 412 directly coupled to CND1504 and the consolidated controller 1302 directly coupled to the CND1502). In certain embodiments, the second network associated with thefirst CND 1502 may be a separate network relative to the second networkassociated with the second CND 1504, but may be a same type of network(e.g., an Ethernet network) and/or may utilize the same or electricallycoupled hardware relative to each other. The example of FIG. 15illustrates the CND 1504 as having primary network regulation for thefirst network 406, but regulation of the first network 406 may bedistributed, shared, regulated according to end points, applications,and/or flows, or the like. In certain embodiments, regulation of thesecond network(s) may be performed by only one of the CNDs 1502, 1504,and/or distributed, shared, regulated according to end points,applications, and/or flows.

A number of representative aspects of FIG. 15 are described following,any one or more of which may be present in certain embodiments. Anexample aspect of FIG. 15 includes shared regulation of networks by theCNDs 1502, 1504, with either of the CNDs 1502, 1504 fully or partiallycapable to support regulation of all networks, for example if an endpoint, network, the other CND (or portion), and/or controllerexperiences a failure, a fault, or diminished operational capability. Anexample aspect of FIG. 15 includes primary regulation of networks by onethe CNDs 1502, 1504, with the other CND capable to fully or partiallysupport regulation of the networks, for example if an end point,network, primary CND, and/or controller experiences a failure, fault, ordiminished operational capability. An example aspect of FIG. 15 includesone or more of the consolidated controllers 1302, 1506 capable to atleast partially assume control operations for the other of theconsolidated controllers 1506, 1302 if one of the consolidatedcontrollers loses capability, connectively with an end point, or thelike. In certain embodiments, the CNDs 1502, 1504 are capable to passparameters that were previously only available to the originalcontroller 1302, 1506 in response to the assumption of the controloperations by the replacement controller 1506, 1302. In certainembodiments, the redundant network routing availability is usable by theCNDs 1502, 1504, to provide at least partial connectivity between endpoints that lose connection when a part of the network goes down. TheCNDs 1502, 1504 may provide equivalent parameters (e.g., another endpoint that is capable to provide equivalent data), substitute parameters(e.g., another end point that is capable to provide a substitute orbackup parameter that is usable, at least partially, as a substitute forthe lost parameter), the same parameters (e.g., where the data from theoriginal end point, or the same data value from another end point, canbe routed through the remaining network infrastructure), and/or mayprovide managing parameters such as controller hand-off communications,heart beat or status communications, or the like. In certainembodiments, one or both of the CNDs 1502, 1504 or CND portions may beco-located with another system component, such as one of theconsolidated controllers 1302, 1506. In certain embodiments, networkrouting for networks on the vehicle is provided to yield distinct riskprofiles for networks on the vehicle, reducing the risk of a singlefailure rendering the vehicle inoperable for the mission, and/orinoperable for at least a limp home operation, controlled shutdown, datacapture, or the like. In certain embodiments, controller, CND, and/orconsolidated controller locations may be selected to provide distinctrisk profiles for related devices, reducing the risk of a single failurerendering the vehicle inoperable for the mission, and/or inoperable forat least a limp home operation, controlled shutdown, data capture, orthe like. In certain embodiments, network routing for networks on thevehicle is provided to yield a lower operating cost, installation cost,integration cost, overall risk profile, distribution of weight and/orfootprint of components on the vehicle, or the like.

Referencing FIG. 16, a number of illustrative examples of messagetranslation and/or message encapsulation embodiments are schematicallydepicted. The examples of FIG. 16 are illustrative to depict certainaspects of the present disclosure, but are non-limiting to thedisclosure. In certain embodiments, operations depicted in FIG. 16 maybe performed in whole or part by a CEG, a CES, a translation circuit,and/or the CND, and in certain embodiments operations depicted in FIG.16 may be regulated by the CND. The first example message translation1602 includes a message from a first network having a payload 1610 andother frame information 1608. The other frame information may includeheaders, trailing aspects and/or termination bits, and further may bedetermined by the relevant protocol, network type, source end point,destination end point, or other aspects as known in the art. In certainembodiments, the payload 1610 may be the message data, a data valueexpressed by the message, or other information considered to be thecontent of the message. However, in certain embodiments, for certainoperations, during certain operating conditions, and/or for certain endpoints, the payload 1610 may be some other aspect of the message. Forexample, a network monitoring operation may utilize a time stamp,acknowledgment information, source and/or destination information, orother portions of the message as the payload. The example messagetranslation 1602 includes separating the payload 1610, and packaging thepayload into a new frame (or packet) 1612, within information configuredfor the target network. Additionally or alternatively, the new frame1612 may include adjustment of an identifier (e.g., a source ordestination), a time stamp, or other information allowing end points ondisparate networks to be abstracted from knowledge about each other. Incertain embodiments, the payload 1610 may be processed, for example tochange units utilized, bit depth (e.g., 2 bytes versus 4 bytes),expressed precision, floating point or fixed point conversions, or thelike.

The second example message translation 1604 includes the originalmessage 1608, 1610, and is fully encapsulated within a new frame 1612,for example to provide a target end point with the original message asprovided by the original source (e.g., allowing a previously developedalgorithm to operate as-is, without having to translate to a newmessage; to allow for certain network monitoring operations utilizingthe full original message, etc.). In certain embodiments, either theoriginal payload 1610 or message frame 1608 may be processed, forexample processing the payload as described preceding, updating a sourceidentifier, time stamp, or the like to a new convention that istranslated to abstract end points from each other, but providingotherwise equivalent or systematically adjusted information.

The third example message translation 1606 includes the original message1608, 1610, with an adjusted payload 1614. The adjustment to the payload1614 can include translation of the payload 1614 in some manner (e.g., acorrected value, a virtually sensed or modeled value based on theoriginal payload 1610, an up-sampled or down-sampled payload 1610, orthe like), and may additionally or alternatively include processing ofthe payload. The third example message translation 1606 describes anadjusted payload 1614, although an adjustment may additionally oralternatively be performed on other portions of the message frame 1608.In the third example message, a new frame 1612 is applied forcommunication to another network.

Referencing FIG. 17, a schematic depiction of an operation todown-sample a sequence of messages 1702 is schematically depicted. Inthe example of FIG. 17, a message sequence 1702 (e.g., a series of fivecommunications, in the example) is received, for example, at a networkinterface circuit of one of the network gateway devices. In the exampleof FIG. 17, the down-sampling operation is responsive to anydown-sampling operations described herein, for example to match areceiving end point data rate, to provide the data represented by themessages 1702 at a scheduled rate, to manage bandwidth on a network ofthe vehicle and/or for extra vehicle communications, to preserve buffermemory, or for any other purpose, including any down sampling operationsof the present disclosure. In the example of FIG. 17, the down-samplingdevice 1704, which may be a translation circuit, network interfacecircuit, the CND, a circuit associated with the CND, a circuit regulatedby the CND, or the like, generates a translated sequence of messages1708 (e.g., processed as depicted in FIG. 16 and the related disclosure,and/or according to any other message translation and/or messageprocessing operations set forth herein). The example of FIG. 17 depictsthe translated sequence of messages 1708 for clarity of the description.However, the translated sequence of messages 1708 may not all be presentat the same time, for example as messages are translated and sent theymay be removed, deleted, expire from a cache, etc. The sequence ofmessages 1708 is depicted to illustrate aspects of the presentdisclosure. Additionally or alternatively, translation of the messages1708 may be performed after down-sampling operations are performed, forexample to reduce utilization of processing resources. For example, someof the messages may be eliminated as a part of the down-sampling beforethe translation operations (e.g., replacement of frame portions ormetadata, encapsulation, processing of the payload and/or frameportions, etc.) are performed. In the example of FIG. 17, a down-sampledsequence of messages 1706 is provided and communicated, for example to adifferent network gateway device, to a different network of the vehiclefrom which the first sequence of messages 1702 is received, to anexternal device (e.g., service tool, cloud server, operator's mobiledevice, etc.), and/or stored on a memory storage device on the vehicle(e.g., for later data collection operations, as a part of stored vehicledata, etc.). In the example, the five messages of the original sequence1702 are down-sampled to three messages of the down-sampled sequence1706. The down-sampling operations can include converting selectedmessages from the original sequence 1702, for example changing anoriginal 10 ms data stream 1702 to a down-sampled 20 ms data stream 1706by utilizing every other data message. The down-sampling operations may,additionally or alternatively, include interpolation of data messagesbetween original values. For example, where the original data stream1702 is a 40 ms data stream, and the down-sampled data stream 1706 is a100 ms data stream, the down-sampling may include either taking theclosest-in-time messages, or performing an interpolation operation(e.g., applying a linear fit, spline fit, polynomial fit, or otherinterpolation operation for spanning data points), to be utilized as thedown-sampled messages 1706.

Spanning data points or values, as utilized herein, indicate data valuesin the down-sampled messages 1706 that do not align in time with acorresponding original data message 1702. Non-spanning data points orvalues, as utilized herein, indicate data values in the down-sampledmessages 1706 that align in time, or are synchronized, with thecorresponding original data message 1702. It will be understood thatmessages of the original data message 1702 and down-sampled messages1706 may additionally or alternatively have a phase difference, andaccordingly, in certain embodiments, any or all of the original datamessages 1702 may be non-spanning messages. In certain embodiments, evenwhere a phase difference between the original data message 1702 and thedown-sampled messages 1706 are present, certain messages of the originaldata messages 1702 may be treated as non-spanning or synchronized datamessages, for example to provide a baseline down-sampled message 1706stream that follows the progression character (e.g., in the time domain)of the original data message 1702 stream, and/or where any phasedifference can be ignored for the purpose of devices or operationsutilizing the down-sampled message 1706 (e.g., where such devices oroperations have a response time, a required reaction time, or the like,that is significantly greater than the magnitude of any such phasedifference).

In a further example, synchronized data values (e.g., every 5^(th) datavalue when converting from 40 ms to 100 ms) may be utilized directly, ormay also utilize a fitting function (e.g., to provide a smooth,filtered, or otherwise processed stream of data values). In certainembodiments, it may be desirable to utilize actual data values providedfrom the first data stream 1702 as the down-sampled data values 1706,where minor transient behavior from the different time steps is eithernot relevant to how the down-sampled data value 1706 is utilized, orwhere time stamp data is also communicated with the messages andaccordingly the differential time steps between messages can beaccounted for in processes that utilize the down-sampled data 1706. Incertain embodiments, it may be desirable to utilize smoothed data valuesthat simulate the time response behavior of the underlying data, whichmay be managed utilizing interpolated data for spanning data values(e.g., processes that are responsive to a rate-of-change in thedown-sampled data 1706, such as threshold checks on the rate-of-change).In certain embodiments, for example where a downstream process isparticularly sensitive to time variation of the data messages 1702(e.g., a derivative portion of a PID controller), it may be desirable toensure that all down-sampled data messages 1706 are generated from thesame process, and interpolation operations (or smoothing, filtering, ormoving average values) may be performed to generate both spanning andnon-spanning data values 1706. In certain embodiments, down-sampled datamessages 1706 may further include metadata or other embedded informationindicating whether the message corresponds directly to an original datamessage 1702 or is a processed message (e.g., allowing more than one usefor the down-sampled data messages 1706, diagnostic operations for adevice providing the original data message 1702, and/or for any otherpurpose).

It can be seen that the down-sampling operations of FIG. 17 allow forcommunication between devices and/or procedures having differing datarate capabilities, expectations, and/or usage rates of the down-sampleddata. Additionally, down-sampling operations of FIG. 17 allow forreduction in network utilization while providing sufficient data fordevices and/or procedures to perform the intended functions, and withexpected time domain response (e.g., derivative behavior, integratingbehavior, step change response, etc.) for proper functionality ofdevices and procedures that may rely upon the time dynamics ofcommunicated data values. It can be seen that the down-samplingoperations of FIG. 17 allow for a progressive updating of communicationaspects (e.g., components, devices, procedures, and/or operations eachcommunicatively interacting with a network and/or other components,devices, procedures, and/or operations) of a mobile application having amixed network configuration and/or a mix of legacy communication aspects(e.g., having a lower data rate capability and/or data rate expectation,and/or distinct network protocols, characteristics, message types, andthe like) with updated communication aspects (e.g., having a higher datarate capability and/or data rate expectation, and/or distinct networkprotocols, characteristics, message types, and the like).

Referencing FIG. 18, a schematic depiction of an operation to up-samplea sequence of messages 1802 is depicted. In the example of FIG. 18, amessage sequence 1806 (e.g., a series of three communications, in theexample) is received, for example, at a network interface circuit of oneof the network gateway devices. In the example of FIG. 18, theup-sampling operation is responsive to any up-sampling operationsdescribed herein, for example to match a receiving end point data rate,to provide the data represented by the messages 1806 at a scheduledrate, to manage bandwidth on a network of the vehicle and/or for extravehicle communications, to preserve buffer memory, or for any otherpurpose, including any up sampling operations of the present disclosure.In the example of FIG. 18, the up-sampling device 1804, which may be atranslation circuit, network interface circuit, the CND, a circuitassociated with the CND, a circuit regulated by the CND, or the like,generates a translated sequence of messages 1808 (e.g., processed asdepicted in FIG. 16 and the related disclosure, and/or according to anyother message translation and/or message processing operations set forthherein, and). The example of FIG. 18 depicts the translated sequence ofmessages 1808 for clarity of the description. However, the translatedsequence of messages 1808 may not all be present at the same time, forexample as messages are translated and sent they may be removed,deleted, expire from a cache, etc. The sequence of messages 1808 isdepicted to illustrate aspects of the present disclosure. Additionallyor alternatively, translation of the messages 1808 may be performedafter up-sampling operations are performed, for example to reduceutilization of processing resources.

For example, some of the messages may be eliminated or adjusted as apart of the up-sampling before the translation operations (e.g.,replacement of frame portions or metadata, encapsulation, processing ofthe payload and/or frame portions, etc.) are performed. In the exampleof FIG. 18, an up-sampled sequence of messages 1802 is provided andcommunicated, for example to a different network gateway device, to adifferent network of the vehicle from which the first sequence ofmessages 1806 is received, to an external device (e.g., service tool,cloud server, operator's mobile device, etc.), and/or stored on a memorystorage device on the vehicle (e.g., for later data collectionoperations, as a part of stored vehicle data, etc.). In the example, thethree messages of the original sequence 1806 are up-sampled to fivemessages of the up-sampled sequence 1802. The up-sampling operations caninclude converting selected messages from the original sequence 1806,for example changing an original 50 ms data stream 1806 to an up-sampled20 ms data stream 1802 by inserting one or more generated messages 1810.The up-sampling operations may, additionally or alternatively, includeinterpolation and/or extrapolation of data messages between originalvalues. For example, where the original data stream 1806 is a 50 ms datastream, and the up-sampled data stream 1802 is a 20 ms data stream, theup-sampling may include either taking the closest-in-time messages, orperforming an interpolation and/or extrapolation operation (e.g.,applying a linear fit, spline fit, polynomial fit, moving average,and/or a low-pass filtered progression between available data pointsand/or between an available data point and a predicted next data point),to be utilized as the up-sampled messages 1802.

Spanning data points or values, as utilized herein, indicate data valuesin the up-sampled messages 1802 that do not align in time with acorresponding original data message 1806. Non-spanning data points orvalues, as utilized herein, indicate data values in the up-sampledmessages 1802 that align in time, or are synchronized, with thecorresponding original data message 1806. It will be understood thatmessages of the original data message 1806 and up-sampled messages 1802may additionally or alternatively have a phase difference, andaccordingly, in certain embodiments, any or all of the original datamessages 1806 may be non-spanning messages. In certain embodiments, evenwhere a phase difference between the original data message 1806 and theup-sampled messages 1802 are present, certain messages of the originaldata messages 1806 may be treated as non-spanning or synchronized datamessages, for example to provide a baseline up-sampled message 1802stream that follows the progression character (e.g., in the time domain)of the original data message 1806 stream, and/or where any phasedifference can be ignored for the purpose of devices or operationsutilizing the up-sampled message 1802 (e.g., where such devices oroperations have a response time, a required reaction time, or the like,that is significantly greater than the magnitude of any such phasedifference).

In a further example, synchronized data values (e.g., every other datavalue when converting from 50 ms to 20 ms, such as the 0 ms phase valueand the 100 ms phase value) may be utilized directly, or may alsoutilize a fitting function (e.g., to provide a smooth, filtered, orotherwise processed stream of data values). In certain embodiments, itmay be desirable to utilize actual data values provided from the firstdata stream 1806 as the up-sampled data values 1802, for example whereminor transient behavior from the different time steps is either notrelevant to how the up-sampled data value 1802 is utilized, or wheretime stamp data is also communicated with the messages and accordinglythe differential time steps between messages can be accounted for inprocesses that utilize the up-sampled data 1802. Accordingly, in certainembodiments, each message of the up-sampled data values 1802 maycorrespond directly to one or more of the first data stream 1806 values(e.g., selecting a synchronized one, a closest one, and/or a most recentone (e.g., holding the communicated value until a next value isavailable) of the first data stream 1806 values).

In certain embodiments, it may be desirable to utilize smoothed datavalues that simulate the time response behavior of the underlying data(e.g., original messages 1806), which may be managed utilizinginterpolated/extrapolated data for spanning data values (e.g., processesthat are responsive to a rate-of-change in the up-sampled data 1802,such as threshold checks on the rate-of-change), and/or also fornon-spanning data values. In certain embodiments, for example where adownstream process is particularly sensitive to time variation of thedata messages 1806 (e.g., a derivative portion of a PID controller), itmay be desirable to ensure that all up-sampled data messages 1802 aregenerated from the same process, and interpolation/extrapolationoperations (and/or smoothing, filtering, and/or moving average values)may be performed to generate both the spanning and non-spanningup-sampled data values 1802. In certain embodiments, non-spanningup-sampled data values 1802 are utilized directly (e.g., to provide anup-sampled data 1802 stream having the actual content of the datamessages 1806 to the extent possible), and spanning up-sampled datavalues are processed as described herein. In certain embodiments, alloriginal messages 1806 are provided in the up-sampled data 1802 stream,with additional non-spanning messages added to achieve the data rate ofthe up-sampled data 1802 stream (e.g., to provide all of the originalmessages 1806, and additionally support the up-sampling rate). Incertain embodiments, up-sampled data messages 1802 may further includemetadata or other embedded information indicating whether the messagecorresponds directly to an original data message 1806 or is a processedmessage (e.g., allowing more than one use for the up-sampled datamessages 1802, diagnostic operations for a device providing the originaldata message 1806, and/or for any other purpose).

In certain embodiments, spanning up-sampled data values 1802 may bedetermined based on predicted values between non-spanning data values,which may be performed based on a virtual sensor (e.g., a model of thevalue utilizing other information available in the system) and/or anextrapolation fitting operation. In certain embodiments, determinationof spanning up-sampled data values 1802 additionally or alternativelyincludes providing predicted and/or interpolated/extrapolated valuesthat provide an expressed rate of change of the up-sampled data values1802 determined according to the original data values 1806 and/oradjusted according to the characteristics of a device, component,operation, and/or procedure utilizing the up-sampled data values 1802.For example, up-sampling operations may include performing a predictiveoperation and/or interpolation/extrapolation to determine a rate ofchange for the value, and providing a final spanning up-sampled datavalue 1802 that provides the predicted rate of change for the up-sampleddata value 1802. In certain embodiments, operations to provide theup-sampled data values 1802 include an operation to determine a rate ofchange (or derivative) determination operation in a device utilizing theup-sampled data values 1802, and adjusting the rate of change of theup-sampled data values 1802 in response to parameters of the rate ofchange determination in the device—for example interpreting data relatedto a time step utilized for the derivative operation (e.g., ΔT/5 ms, orchange-in-temperature per 5 milliseconds) and/or a time constant (e.g.,a time constant of a low-pass filter, a time constant implicit in amoving average calculation, etc.), where the up-sampled data value 1802is adjusted to provide a desired response in the rate of changecalculations that will be performed on the up-sampled data values 1802.For example, where up-sampling operations have a significant differencein time steps between the original data value 1806 and the up-sampleddata value 1802 (e.g., 50 ms to 5 ms), operations such as a linearinterpolation/extrapolation of data values may provide significantdistortion to the output of, for example, a low-pass filter operated bya device utilizing the up-sampled data value 1802, which may beconfigured to process true 5-ms data. Accordingly, in the example,operations to up-sample the original data values 1806 may includeadjusting the original data values 1806 in accordance with a predictedresponse of a 5-ms device determining the values, which may providesignificant differences in trajectory of the up-sampled data value 1802between non-spanning data points relative to simple linearextrapolation, moving averages, or the like. Operations to adjust theexpressed rate of change may be performed for up-sampled data 1802,and/or for down-sampled data 1706, or may be omitted.

In certain embodiments, configuration information for up-sampling and/ordown-sampling operations, such as: whether non-spanning original datavalues 1702, 1806 are to be utilized directly; metadata to be storedwith up-sampled and/or down-sampled data 1802, 1706; processingoperations to be performed on spanning and/or non-spanning data values;whether all original data values 1702, 1806 are to be communicated;operations to provide an expressed rate of change in the up-sampledand/or down-sampled data 1802, 1706; and/or parameters of a rate ofchange determination in a device utilizing the up-sampled and/ordown-sampled data 1802, 1706 (e.g., filter constants, derivativeoperations, etc.), may be provided in a memory storage locationaccessible to a controller and/or circuit performing up-sampling and/ordown-sampling operations. Any such configuration information may beprovided in whole or part at design time, such as when configuring amobile application and devices communicating with various networks ofthe mobile application, and/or may be provided or updated duringrun-time operations. In certain embodiments, one or more aspects of theconfiguration information for up-sampling and/or down-samplingoperations may be provided as a part of a policy, configurationinstructions, and/or a configuration table, which may be accessible to aCND 108 regulating communications between devices on separate networksof the mobile application. In certain embodiments, one or more aspectsof the configuration information for up-sampling and/or down-samplingoperations may include default values which may be adjusted and/orupdated, including as a part of a policy, configuration instructions,and/or a configuration table.

Referencing FIG. 19, an example system, which may form a part of amobile application 1902 or vehicle, includes a first network zone 1904of a vehicle having a first interconnected number of end points 1906,and a second network zone 1908 having a second interconnected number ofend points 1910. The example system includes a CND 1912 interposedbetween the network zones 1904, 1908, where the CND 1912 regulatescommunications between end points 1906 and end points 1910. In theexample of FIG. 19, the first network zone 1904 is a first network, thesecond network zone 1908 is a second network, and the networks 1904,1908 are networks having different network types. In the example of FIG.19, the first network zone 1904 includes a common data bus 1905, e.g.,such as a CAN bus, and the second network zone 1908 utilizes adistributed topology, for example with devices 1910 in communicationwith a switch 1914, which may be a configurable ethernet switch (CES).In the example of FIG. 19, a configurable edge gateway 1916 (CEG)communicates with the first network zone 1904, and is able to readmessages from and/or provide messages to the common data bus 1905. Inthe example of FIG. 19, the CEG 1916 communicates with the CES 1914 onthe second network zone 1908, and the CEG 1916 may appear to the CES1914 as an end point device of the second network zone 1908, and/or maybe associated with a physical and/or logical port of the second networkzone 1908.

In the example of FIG. 19, the CND 1912 performs operations to regulatecommunications between end points 1906, 1910 by configuring operationsof the CEG 1916 and/or CES 1914. The arrangement of FIG. 19 is aschematic depiction for clarity of the present description, depictingdistinct components for the CND 1912, CEG 1916, and CES 1914. However,the CND 1912, CEG 1916, and CES 1914 may be combined in whole or part,provided in a same housing and/or on a same circuit board, and/orsub-divided in whole or part. Additionally or alternatively, one or moreaspects, or all, of the CND 1912, CEG 1916, and/or CES 1914 may bepositioned with another controller in the mobile application 1902, suchas a vehicle controller, and/or with a controller associated with an endpoint 1910. The network zones 1904, 1908 are depicted having separatedphysical components, but the network zones 1904, 1908 may be separatedlogically (e.g., as separate virtual networks on a single physicalbackbone) and/or may be separated in whole or part by a combination ofphysical and/or logical structures. An example embodiment includes thenetwork zones 1904, 1908 separated physically as depicted. An exampleembodiment includes the first network zone 1904 as a CAN bus network,and the second network zone 1908 as an ethernet based network. Anexample embodiment includes the first network zone 1904 as a legacynetwork having end points 1906 that are legacy devices and/or legacycompatible devices, and the second network zone 1908 having end points1910 that are new, updated, upgraded, and/or migrated devices.

Example operations to regulate communications between end points 1906,1910 include, without limitation operations such as those describedfollowing. Operations to regulate may be performed for end points, forassociated groups of end points, and/or for network zones. Associatedgroups of end points may be associated according to flows, applications,service groups, controllers, vehicle functions, source addresses forcommunications, and/or destination addresses for communications. Incertain embodiments, applications, service groups, and/or flows may beprovided with an identifier as an implementation to associate relatedcomponents such as end points. Operations to regulate may be performedby, without limitation, the CND, a network gateway, a network interfacecircuit, and/or a gateway interface circuit. Regulating operations aredescribed in the context of certain example regulating devicesthroughout the present disclosure, but embodiments may be configured tohave other devices perform the regulating. Example communication and/orregulating operations include:

-   -   providing a communication between a first end point 1906 and a        second end point 1910 (in either direction), including        configuring the communication (e.g., protocols, message        information, metadata, parameter units, etc.) for the receiving        network zone and/or end point device;    -   encapsulating a message from the first network zone 1904 and        providing the encapsulated message to the second network zone        1908;    -   determining if a requesting device (and/or associated flow) on        one of the network zones (1904, 1908) has permission to request        a communication from a device on the other one of the network        zones, and providing the communication in response to the        permission determination;    -   adjusting at least one of a data rate, requested resolution,        and/or requested response time of a communication between        devices of the network zones based on a permission determination        for a requesting device, a communication performance of a        requesting and/or a providing device, and/or a network        performance parameter (e.g., current available bandwidth,        absolute or current network capability, network utilization,        etc.) of one or both network zones, and/or a priority value        associated with a requesting device (and/or associated flow) for        a communication;    -   performing an up-sampling and/or down-sampling operation on the        communicated data between the network zones;    -   mirroring communications from a first end point 1906 to a port        of the second network zone 1908, including encapsulating,        configuring, processing, and/or up-sampling or down-sampling the        mirrored communications;    -   providing a communication from a first end point 1906 to a        device coupled to the second network zone 1908, such as a        diagnostic device, OBD device, service tool, manufacturing tool,        OEM tool, and/or network monitoring device, and/or where        providing the communication includes encapsulating, configuring,        processing, and/or up-sampling or down-sampling the provided        communications, and/or where the provided communications may be        unicast, multi-cast, and/or provided as a subscription service;    -   providing a communication from a second end point device 1910 to        a device coupled to either the first network zone 1904 or the        second network zone 1908, such as a diagnostic device, OBD        device, service tool, manufacturing tool, OEM tool, and/or        network monitoring device, and/or where providing the        communication includes encapsulating, configuring, processing,        and/or up-sampling or down-sampling the provided communications,        and/or where the provided communications may be unicast,        multi-cast, and/or provided as a subscription service;    -   providing a communication from a device coupled to the second        network zone 1908, such as a diagnostic device, OBD device,        service tool, manufacturing tool, OEM tool, and/or network        monitoring device, to a first end point 1906, and/or where        providing the communication includes encapsulating, configuring,        processing, and/or up-sampling or down-sampling the provided        communications, and/or where the provided communications may be        unicast, multi-cast, and/or provided as a subscription service;        -   further providing the communication as a command value, for            example where the first end point 1906 executes operations            relating to the mission of the mobile application in            response to the command value (e.g., setting a set point,            target value, or threshold in response to the command            value);    -   providing a communication from a device coupled to the second        network zone 1908, such as a diagnostic device, OBD device,        service tool, manufacturing tool, OEM tool, and/or network        monitoring device, to a first end point 1906, and/or where        providing the communication includes encapsulating, configuring,        processing, and/or up-sampling or down-sampling the provided        communications, and/or where the provided communications may be        unicast, multi-cast, and/or provided as a subscription service;        -   further providing the communication as a test execution            value, for example where the first end point 1906 executes            operations relating to an active text execution operation of            the mobile application in response to the command value            (e.g., performing certain operations for a service test,            active diagnostic operation, or the like);    -   providing a communication from a first end point 1906 to a        number of second end point 1910 devices, where the provided        communications are configured to meet a super-set of the        requirements of the second end point 1910 devices (e.g., data        rates, resolution, units, etc.), and where the provided        communications may be unicast, multi-cast, and/or provided as a        subscription service;    -   parsing a communication value from a first device (e.g., a first        end point 1906, second end point 1910, and/or device coupled to        a network zone 1904, 1908 such as a diagnostic device, OBD        device, service tool, manufacturing tool, OEM tool, and/or        network monitoring device), determining a target device (e.g.,        communication recipient and/or communication provider responsive        to the communication value) in response to the parsed        communication value, and configuring communications of the        target communication recipient and/or communication provider in        response to the parsed communication value. For example, the        communication value may include a generic and/or normalized        component identifier (e.g., turbine temperature, front passenger        door actuator, etc.), and the CND 1912 determines the respective        end point(s) 1906, 1910 corresponding to the component        identifier according to the current configuration of the mobile        application, and may further determine communication routing,        encapsulation, processing, and the like to translate between the        first device and the target device(s). For example, such        operations allow for the configuration and placement of devices        on network zones to be changed, while not requiring that        devices, service personnel, or other requestors keep track of        the specific configuration and placement of devices;        -   additionally or alternatively, such operations include the            CND 1912 storing configuration information in response to a            configuration change (e.g., replacement or moving of a            device from one network zone to another, changes to the            communication parameters or capabilities of the device,            etc.), and/or performing run-time determinations to confirm            the location, identity, configuration, communication            parameters and/or capabilities of devices, which may be            utilized during run-time operations and/or stored for later            utilization and/or as a default configuration subject to            further updates;    -   performing any one or more of these operations on a group or        sub-group of devices, for example where devices are consolidated        in relation to a single end point 1906, 1910 but may be treated        as separate devices by other end points or devices in        communication with a network zone 1904, 1908 (e.g., a diagnostic        device, OBD device, service tool, manufacturing tool, OEM tool,        and/or network monitoring device). For example, such operations        allow for multiple configurations, updates, and/or upgrades of        the mobile application where a first configuration has two (or        more) devices with separate end points 1906, 1910, and a second        configuration has the two (or more) devices utilizing a single        end point 1906, 1910 (and/or the two devices consolidated into a        single device). Example and non-limiting embodiments include        consolidation of multiple sensors communicating to a network        zone 1904, 1908 through a single interface (e.g., a smart sensor        having network communication capability, a multi-plexed signal,        etc.), and/or replacing an interface of multiple components        behind a single network interface (e.g., a single communicating        device, such as an edge gateway or a configurable edge gateway,        that interfaces to a single network zone 1904, 1908 as a single        end point 1906, 1910 and manages communications for related        devices). In a further example, such operations allow for        devices to communicate across network zones without regard to        changes in the configuration, to support upgrades and updates        that relate to device relationships with end points 1906, 1910,        and to support backwards compatibility (e.g., a later        configuration, a later control distribution among devices, and        the like, where operations of the CND 1912 allow an earlier        system having a distinct configuration to support the updated        configuration and/or control distribution among devices);        -   additionally or alternatively, such operations include the            CND 1912 storing configuration information in response to a            configuration change (e.g., intervention of a single end            point between more than one device and a network zone,            consolidation of devices, etc.), and/or performing run-time            determinations to confirm the location, identity,            configuration, communication parameters and/or capabilities            of devices, and/or consolidation status of devices, which            may be utilized during run-time operations and/or stored for            later utilization and/or as a default configuration subject            to further updates;    -   performing any one or more of these operations on a group or        sub-group of devices, for example where devices are distributed        between more than one end point 1906, 1910 but may be treated as        a single devices by other end points or devices in communication        with a network zone 1904, 1908 (e.g., a diagnostic device, OBD        device, service tool, manufacturing tool, OEM tool, and/or        network monitoring device). For example, such operations allow        for multiple configurations, updates, and/or upgrades of the        mobile application where a first configuration includes a device        with a single end point 1906, 1910, and a second configuration        has the device (or portions thereof) utilizing more than one end        point 1906, 1910 (and/or a previously consolidated device made        up of two or more separate devices in the second configuration).        Example and non-limiting embodiments include separation of a        group of sensors communicating to a network zone 1904, 1908        through a single end point 1906, 1910 (e.g., a smart sensor        having network communication capability, a multi-plexed signal,        etc.) into one or more sensors each having a separate end point        1906, 1910 (and/or sub-groups of the multiple sensors each        having a separate end point). In a further example, such        operations allow for devices to communicate across network zones        without regard to changes in the configuration, to support        upgrades and updates that relate to device relationships with        end points 1906, 1910, and to support backwards compatibility        (e.g., a later configuration, control distribution among        devices, and the like, where operations of the CND 1912 allow an        earlier system having a distinct configuration to support the        later configuration);        -   additionally or alternatively, such operations include the            CND 1912 storing configuration information in response to a            configuration change (e.g., division of devices behind a            single end point on a single network zone into more than one            end point and/or across more than one network zone), and/or            performing run-time determinations to confirm the location,            identity, configuration, communication parameters and/or            capabilities of devices, and/or consolidation status of            devices, which may be utilized during run-time operations            and/or stored for later utilization and/or as a default            configuration subject to further updates;    -   implementation of a service oriented architecture, wherein the        CND 1912 determines available services (e.g., data parameters        available for communications, command values available for        execution, and/or configurations of these such as rate        information, units, resolution, precision, accuracy,        availability descriptions, dependent data and/or operating        conditions, etc.), publishes the available services, and/or        determines subscribing clients (e.g., devices, flows, and/or end        points) for the available services;        -   additionally or alternatively, such operations include the            CND 1912 determining permissions and/or authorization for            publishing available services, for seeing available services            (and/or portions of the available services), and/or            subscribing to available services;        -   additionally or alternatively, such operations include the            CND 1912 determining subscribing entities as an end point, a            device, a flow, and/or an external device such as a            diagnostic device, OBD device, service tool, manufacturing            tool, OEM tool, and/or network monitoring device;        -   additionally or alternatively, such operations include the            CND 1912 determining a priority of service oriented            communications, which may be dependent upon the publishing            device, end point, or related flow, and/or dependent upon            the subscribing device, end point, or related flow;        -   additionally or alternatively, such operations include the            CND 1912 adjusting the service oriented architecture            operations in response to operating conditions (e.g., mobile            application operating conditions, network status of one or            more affected network zones, communication status of one or            more external devices, etc.);        -   additionally or alternatively, such operations include the            CND 1912 accessing stored information setting forth            available services, publication parameters (permissions,            priority, related operating conditions, etc.), and/or            subscribing entity information;        -   additionally or alternatively, such operations include the            CND 1912 updating stored information in response to one or            more of: a received update, such as a policy description, a            service configuration description, etc.; run-time updates            from end-points, devices, and/or flows, for example, and            without limitation, executed during start-up or shut-down            operations of the mobile application;        -   additionally or alternatively, such operations include the            CND 1912 implementing a service oriented architecture based            on run-time operations, with or without storing the            information and/or updating the stored information; and/or        -   additionally or alternatively, allowing updates to the            stored information, run-time updates to the stored            information, and/or run-time operations implementing the            service oriented architecture, in response to a priority            and/or a permission associated with the device, end point,            and/or flow requesting the update and/or run-time            implementation;    -   additionally or alternatively, operations of an example CND 1912        include adjusting operations of any one or more of the foregoing        in response to operating conditions of the mobile application        (e.g., adjusting communication operations during certain        operations, such as: high power operation; high transient        operation; shut-down operation; start-up operation; a selected        operating mode such as vocational operation, power take-off        (PTO) operation, charging operation, cruise control operation,        autonomous vehicle operation, etc.). Adjustments to        communication may be qualitative (e.g., allowing or disallowing        certain communication types, certain communication priority        thresholds, etc., during certain operating conditions; and/or        capturing certain data values during certain operating        conditions as a data capturing event), quantitative (e.g.,        controlling a rate of communications, a network zone        utilization, external device communication rates, etc.), or a        combination of these (e.g., controller a rate of communications        for certain communication types, etc.) of these, and may include        increasing or decreasing capability of communications according        to the operating condition and/or the communication type (e.g.,        providing for decreased device communication capability during        shut-down operations, but increasing external device        communication capability during the shut-down operations;        increasing device communication capability for certain devices        or flows, but reducing device communication capability for other        devices or flows during start-up operations, etc.);    -   additionally or alternatively, operations of an example CND 1912        include adjusting operations of any one or more of the foregoing        in response to off-nominal operating conditions relating to the        mobile application, where the off-nominal operating conditions        include conditions such as: degradation of a network zone (e.g.,        loss of throughput, loss of communication with one or more end        points of a network zone, injection or presence of noise onto a        network zone, injection of traffic onto a network zone, a        physical failure of at least a portion of the network zone,        etc.); a fault condition of one or more devices (e.g., where the        CND 1912 adjusts a data source related to the faulted device,        adjusts a data rate related to the faulted device, implements a        back-up data source for the faulted device, re-routes data to a        back-up data recipient for data provided to the faulted device,        implements an event driven data collection scheme where the        fault of the device is an event, etc.); a lost control function        of a vehicle controller (e.g., where the lost control function        indicates that the vehicle controller is lacking a data value to        perform its mission; where the lost control function indicates        that the vehicle controller has lost communication with the        associated network zone; and/or where the lost control function        is an indication, by the vehicle controller or another        controller in the system, that the vehicle controller is not        able to perform its mission or a part of its mission). Further        example operations of the CND 1912, in response to the        off-nominal conditions, include one or more of:        -   providing a data value to a vehicle controller from an            alternate source (e.g., from a different end point, network            zone, etc., and which may include encapsulating,            configuring, processing, and/or up-sampling or down-sampling            the alternate source communications, which may result in            communications that are identical to the original data value            that was lost, or alternative communications that may be            sufficient as a backup data value for the vehicle            controller);        -   providing a data value to a second vehicle controller to            replace all or a portion of the lost control function of the            vehicle controller, for example where a second vehicle            controller is configured to act as a backup for the vehicle            controller, where the second vehicle controller may be fully            capable to perform the lost control function and/or may be            capable to perform alternate operations (e.g., with more            limited capability) in place of the lost control function;            the data value provided to the second vehicle controller may            be a same data value as provided to the vehicle controller,            an alternate source communication (e.g., having a distinct            data rate, resolution, units, precision, etc.), or another            data value altogether (e.g., where the second vehicle            controller utilizes a distinct data set to perform the fully            capable or alternate operations). Additionally or            alternatively, the CND 1912 is capable to provide data from            any network zone 1904, 1908 to the vehicle controller and/or            to the second vehicle controller, which may themselves be on            any network zone 1904, 1908;        -   suppressing communication of one or more data values in            response to the off-nominal condition, for example where a            fault condition, device or end point loss, or the like            indicates that the one or more data values are not being            utilized; where the one or more data values are low priority            in view of the off-nominal condition; and/or where the one            or more data values are indicated as invalid in view of the            off-nominal condition (e.g., sensor values from a sensor            having a fault or failed condition);        -   shifting of communications from a first network zone (e.g.,            a degraded network zone) to a second network zone, such as            when end points and/or devices are reachable through more            than one network zone (e.g., where the zones are logically            separated but physically coupled, where more than one            physical route is available between relevant end points            (e.g., reference FIG. 15), and/or where a second vehicle            controller and/or a second end point coupled to the second            network zone is capable to perform the operations (or a            portion thereof, and/or an alternate thereof) of a first            vehicle controller and/or first end point coupled to the            first network zone;        -   repeating communications from a first network zone (e.g., a            degraded network zone) on a second network zone;        -   shifting an end point from a first network zone (e.g., a            degraded network zone) to a second network zone, for example            where the shifted end point is physically coupled, or            couplable, to both the first network zone and the second            network zone (e.g., where the separation between the network            zones is a logical separation, and/or where the end point is            reachable through more than one network zone, such as            depicted in FIG. 15), where operations of the CND 1912            include adjusting an addressing, protocol, encapsulation            operations, and/or any other operations to effect the shift            of the end point, which may further include updating the            location of the shifted end point with other devices/end            points in the system, or translating communications with            other devices/end points in the system without notification            of the shift;        -   combinations of these, such as shifting an end point from a            first network zone to a second network zone, and shifting            related communications to the second network zone and/or            repeating related communications on the second network zone;    -   regulate communications between end points of a first network        zone (and/or one or more additional network zones) and an        external device (e.g., a diagnostic device, OBD device, service        tool, manufacturing tool, OEM tool, network monitoring device,        operator device, cloud computing device, and/or a third party        application), where the regulating between end points of the        first network zone and the external device(s) including any one        or more of the foregoing operations, and/or may further include:        limiting communications according to off-nominal conditions of a        component (e.g., an end point, device, flow, network zone, etc.)        of the system; limiting communications according to an operating        condition of the mobile application; limiting communications        according to a permission and/or priority of the end point(s),        associated flows, and/or the external device; limiting        communications according to an aggregated data value (e.g.,        corresponding to an associated data service provider for the        communication; corresponding to a group of end points;        corresponding to an associated flow; and/or corresponding to an        entity related to any one or more of these), which may be        aggregated according to time (e.g., daily, weekly, monthly,        etc.), operating condition (e.g., trip, event, etc.), and/or        where the data value includes one or more of a total data        sent/received value, a data rate value, and/or combinations of        these; and/or limiting communications according to an external        data access type (e.g., cellular, WiFi, Bluetooth, hardware/port        plug-in, etc.); and/or    -   combinations of any one or more of the foregoing.

The described operations of the CND 1912 may be included, in whole or inany part, in embodiments set forth throughout the present disclosure. Itwill be understood that permissions and/or priority relative to anyaspect, including end points, related entities (e.g., owner,manufacturer, operator, service personnel, OEM, third-party, etc.),flows, devices (e.g., controllers, actuators, sensors, tools and/orexternal devices, switches, gateways, etc.), may vary according to theoperating condition of the mobile application, and/or the status of oneor more devices (e.g., the same device where a permission or priority isbeing considered, or a different device). Further, the permissionsand/or priority may vary according to the operations and/orcommunications being performed. For example, a given flow may have ahigh priority and/or permission level to see published availableservices, but a low priority and/or permission level to publishavailable services and/or subscribe to available services. In anotherexample, a given end point may have a high priority to communicate adata value to another end point (e.g., on a distinct network zone)during one operating condition (e.g., high power acceleration), but alow priority to communicate the data value to the other end point duringanother operating condition (e.g., steady state cruise controloperation). A priority, as set forth herein, generally relates to acomparison between competing interests for a resource (e.g., networkbandwidth, response time, data storage, access to limited dataresources, etc.), while a permission, as set forth herein, generallyrelates to an ability to perform the requested operation, such as theability to request certain data, metadata, data rates, data storage,access to devices and/or external devices, etc. Accordingly, an aspectmay have a separate priority and permission, such as a high priority andlow permission level (e.g., the aspect has a high priority to access alimited number of data values, functions, etc.), or any othercombination.

Resolution of competing priority interests may be performed in anymanner, such as always favoring the highest priority requestor,providing a weighted response based on the priority (e.g., servicing ahigh priority request more often than a lower priority request), and/orutilizing a credit based scheme that allows lower priority requests tobe serviced after a period of time and/or number of requests.

As utilized herein, the mission of a device (e.g., a controller, endpoint, vehicle, mobile application, etc.) should be understood broadly,and includes at least the related functions, structures, capability, andoperations of the device to support operation of the mobile applicationto perform the intended function or primary function of the mobileapplication. Without limitation to any other aspect of the presentdisclosure, an intended function or primary function of the mobileapplication includes one or more of: motive operation of the mobileapplication, in accordance with the designed motive capabilities (e.g.,with specified torque, speed, responsiveness, etc.); and/or non-motiveoperation (e.g., industrial operations, vocational operations, pumpingoperations, provision of shaft power, movement range, and controlthereof) of the mobile application, with the designed non-motivecapabilities. In certain embodiments, the intended function or primaryfunction of the mobile application includes off-nominal operationalresponse that may be less capable than the designed motive or non-motivecapabilities, such as operation in a limp home mode, communication offault or failure conditions, and/or prevention of further degradation ofthe vehicle and/or mobile application. In certain embodiments, theintended function or primary function of the mobile application includessending and/or receiving external data, performing update operations,facilitating service operations, facilitating update and/or upgradeoperations, or the like. Accordingly, the mission of a device may varybetween mobile applications, according to the current operatingcondition of the mobile application, and/or according to the currentstatus of the mobile application and/or components, devices, and/orcontrollers thereof. One of skill in the art, having the benefit of thepresent disclosure and information ordinarily available whencontemplating a specific mobile application, will readily understand themission of the mobile application, the mission of devices of the mobileapplication, and the variability of these across operating conditionsand status conditions of the mobile application.

Referencing FIG. 20, an example system includes a first network zone1904 having a first risk exposure profile 2002, and a second networkzone 1908 having a second risk exposure profile 2004. In the example ofFIG. 20, the first risk exposure profile 2002 is distinct from thesecond risk exposure profile 2004. A risk exposure profile, as utilizedherein, includes a risk profile experienced by the related component(e.g., the first network zone 1904 and/or second network zone 2004, inthe example of FIG. 20), contemplated in at least one dimension such as:geometrical risk (e.g., risk to the component by virtue of positionwithin the mobile application as installed); environmental risk (e.g.,risk to the component from environmental factors as installed, such astemperatures, contaminants, NVH, EMI, heat transfer environment (e.g.,exposure to radiant energy, conductive heat transfer, and/or convectionor lack of convection), and/or exposure to environmental disturbancessuch as service technician impacts, tool drops, or the like; a failuremode risk (e.g., any identified or evident failure mode of the mobileapplication or components thereof, such as but not limited to: exposureto short circuit events, open wire events, and/or failed components ofthe mobile application (e.g., exhaust components, engine components,aftertreatment components, and/or any other components having failureinducing energy such as elevated temperature, electrical potential,rotational energy, mechanical energy, or the like); a likely risk type(e.g., where a given risk may affect multiple areas or systems of thevehicle, components positioned in those areas or coupled to thosesystems may share a risk type, whereas a component isolated from thoseareas or systems may not share a risk type, regardless of the proximityor other consideration of those components); and/or a likely disturbancerisk (e.g., where a given disturbance, such as a particular serviceevent, operating condition, weather event, off-nominal charging voltage,etc. may affect multiple areas or system of the vehicle, componentspositioned in those areas or coupled to those system may share adisturbance risk, whereas a component isolated from those areas orsystems may not share the disturbance risk, regardless of the proximityor other consideration of these components).

In certain embodiments, the first risk exposure profile 2002 is distinctfrom the second risk exposure profile 2004 in at least one aspect of therisk exposure profiles, such as being positioned in distinct positionson the vehicle (e.g., one on the left side, one on the right side);installed such that a given environmental risk is unlikely to affectboth network zones; installed such that a given failure mode is unlikelyto affect both network zones; installed such that a contemplated risk(e.g., an impact, accident, operational failure, off-nominal operationof a component, etc.) is unlikely to affect both network zones; and/orinstalled such that a contemplated disturbance is unlikely to affectboth network zones. In certain embodiments, a distinction in one riskdimension is sufficient for the risk exposure profiles to bedistinct—for example one or more failures (e.g., complete loss ofelectrical power) may be likely to affect both network zones, but thenetwork zones may nonetheless have distinct risk exposure profiles withregard to other potential failures. Additionally, each network zone mayhave exposure to the same type of risk, such as a first network zonethat is exposed to a frontal impact, and a second network zone that isexposed to a rear impact, but the network zones may nonetheless beconsidered as having distinct risk profiles.

In the example of FIG. 20, a CND 1912 is interposed between the firstnetwork zone 1904 and the second network zone 1908, and is configured toregulate communications between the network zones 1904, 1908. In theexample of FIG. 20, the CND 1912 is capable to communicate with aremaining one of the network zones 1904, 1908 if the other one of thenetwork zones 1904, 1908 experiences a failure or degradation event.Accordingly, the CND 1912 is capable to re-route communications awayfrom the failed network zone 1904, 1908, for example to back-upcontrollers (not shown), other network zones (not shown), or the like.The example of FIG. 20 allows for division of risk of the network zones1904, 1908, allowing for designed redundancy and continued operation ofthe mobile application (whether compliant with the mobile applicationmission, or in a reduced capability operation) if one of the networkzones 1904, 1908 experiences failure or degradation.

Referencing FIG. 21, an example system includes a mobile application1902 having a first network zone 1904, a second network zone 1908, and athird network zone 2108. The network zones 1904, 1908, 2108 may havedistinct risk exposure profiles, and/or any two of the network zones1904, 1908, 2108 may have distinct risk exposure profiles. The examplesystem includes a CEG 2102 communicatively coupled to the first networkzone 1904, a CES 2104 communicatively coupled to the second network zone1908, and a second CES 2106 communicatively coupled to the third networkzone 2108. In the example of FIG. 21, the CND 1912 is distributed, witha portion of the CND 1912 configured to regulate communications of eachnetwork zone 1904, 1908, 2108. The example of FIG. 21 describing thecomponents as a CEG 2102, a CES 2104, and a second CES 2106 is anon-limiting example, and the network zones 1904, 1908, 2108 may be ofany type, with communications operated by any components. In certainembodiments, the corresponding operating components (CEG 2102, CES 2104,and CES 2106, in the example of FIG. 21) may share a risk exposureprofile with the associated network zone 1904, 1908, 2108, or may have adistinct risk exposure profile with the associated network zone 1904,1908, 2108. Additionally or alternatively, the corresponding portions ofthe CND 1912 may share a risk exposure profile with the associatednetwork zone 1904, 1908, 2108. The embodiment of FIG. 21 illustrates thedivision of risk to network zones and components, and the scheduledapplication of redundancy therebetween, that may be applied in anymanner. For example, networks of a same type (e.g., network zone 1908,2108) may have distinct risk exposure profiles, while single instancenetworks (e.g., network zone 1904) may have yet another risk exposureprofile, or a shared risk exposure profile with one of the othernetworks (e.g., network zone 1908, 2108)—for example because the singleinstance network does not have a backup network available, and isalready a single point failure mode in the system. In certainembodiments, one or more of the networks (e.g., network zone 2108) maybe installed to have a very low risk exposure profile (e.g., a centeredposition, isolated from environmental, disturbance, and/or failure moderisks, etc.), and may be configured to operate backup operations for oneor more other networks (e.g., network zone 1908). In certainembodiments, configuration to operate backup operations include one ormore of: redundant connectivity to end points for other networks;provision of backup controllers and/or stored executable commands toperform backup control operations; provision in the related operatingcomponent (e.g., CES 2106) to perform data communication operations forthe other networks; and/or provision in the related CND 1912 portion toperform any or all operations of the other CND 1912 portion(s). Incertain embodiments, any or all of the networks may be configured tooperate backup operations for one or more, or all, of the othernetworks. In certain embodiments, one or more portions of the CND 1912may be co-located with associated ones of the operating components,positioned within a housing with associated ones of the operatingcomponents, and/or positioned on a same board with associated ones ofthe operating components. In certain embodiments, one or more portionsof the CND 1912 may be co-located with controller(s) distributedthroughout the vehicle, positioned within a housing with controller(s)distributed throughout the vehicle, and/or positioned on a same boardcontroller(s) distributed throughout the vehicle. In certainembodiments, one or more portions of the CND 1912 may be provided asexecutable instructions stored on another device (e.g., an operatingcomponent, a vehicle controller, and/or another controller), wherein aprocessor executing the instructions thereby causes the device toperform one or more operations of the CND 1912 portion(s). In theexample of FIG. 21, the CES 2104 regulates communications between thesecond network zone 1908 and the third network zone 2108, communicating,for example, at a port of the CES 2106. In the example of FIG. 21, theCEG 2102 regulates communications between the first network zone 1904and the third network zone 2108, communicating, for example, at aseparate port of the CES 2106.

Example and non-limiting network types of each network zone include oneor more of: a Controller Area Network (CAN), a Media Oriented SystemsTransport (MOST) network, a Local Interconnect Network (LIN), a FlexRaynetwork, a Time-Triggered Protocol (TTP) network, a Low-VoltageDifferential Signaling (LVDS) network, an Audio Video Bridging (AVB)compliant network, a customized version of any one or more of theforegoing, and/or a proprietary version of any one or more of theforegoing.

Referencing FIG. 22, an example apparatus to execute network redundancyoperations is depicted. The example of FIG. 22 is consistent with anembodiment of FIG. 21, but may be applied to any systems and/or mobileapplications as set forth throughout the present disclosure. The exampleapparatus includes a network redundancy circuit 2202 that selectivelyprovides a regulation control command 2204, where one or more CNDportions 1912 are responsive to the regulation control command 2204 toimplement inter-network communications 2206, 2208, 2210 between networkzones (e.g., 1904, 1908, 2108) of the mobile application. Example andnon-limiting inter-network communications 2206, 2208, 2210 includere-routing of data between network zones, shifting of end points betweennetwork zones, a first CND portion assuming regulation of a differentnetwork zone associated with a second CND portion, utilization ofalternate data sources and/or backup control operations, and/oroperations to shift, mirror, and/or suppress one or more data valuesbetween and/or on one or more network zones.

Example and non-limiting regulation control commands 2204 include anindication that one or more end points of a network zone areunavailable, one or more end points of a network zone are in a faultcondition, and/or one or more end points of a network zone are unable toperform mission operations of the respective end point, and/or areproviding invalid communications. In certain embodiments, regulationcontrol commands 2204 include one or more of: commands to utilizealternative data sources and/or backup control operations; commands toshift end points between available network zone(s); and/or commands toshift, mirror, and/or suppress one or more data values between and/or onone or more network zones. In certain embodiments, regulation controlcommands 2204 may include state conditions, such as “Network Zone OneFailed”, a listing of one or more end points, or other values indicatingthe status of end points and/or network zones, where one or more CNDportions 1912 are responsive to the regulation control commands 2204 toimplement communication and/or control redundancy operations accordingto stored configuration information.

Referencing FIG. 23, an example mobile application 1902 includes a firstnetwork zone 1904, a second network zone 1908, a third network zone2322, and a fourth network zone 2324. The network zones may be of anytype. In the example of FIG. 23, the first network zone 1904 is a CANnetwork type, the second network zone 1908 is an ethernet network type,the third network zone 2322 is an ethernet network type, and the fourthnetwork zone 2324 is an electrical signal zone. The example networkzones 1904, 1908, 2322, 2324 are selected to depict certain aspects ofthe present disclosure, and are non-limiting.

In the example of FIG. 23, a CND 1912 regulates communications betweenend points of the network zones by: communicating with a first CEG 1916providing communications between end points of the first network zone1904 and the second network zone 1908, by providing communications at aport of a first CES 1914; communicating with a second CEG 2308 providingcommunications between end points of the fourth network zone 2324 andthe second network zone 1908, by providing communications at a port ofthe first CES 1914; communicating with the first CES 1914 that iscommunicatively couplable to the second CES 2320, thereby allowingcommunications between the second network zone 1908 and the thirdnetwork zone 2322 (and further with the first network zone 1904 and thefourth network zone 2324 by virtue of the CEG 1916, 2308communications); and communicating with a second CES 2320 providingcommunications between end points of the third network zone 2322 and theother network zones 1904, 1908, 2324 (through the second network zone1908, in the example of FIG. 23). The CND 1912 further regulatescommunications between end points of the network zones 1904, 1908, 2322,2324 and an external communication device 2326, for example bycommunicating permissions, priority information, and the like to thefirst CES 1914 and/or the second CES 1916, which are selectively able tocommunicate with the external communication device 2326 (e.g., a headunit). The CND 1912 in the example of FIG. 23 is depicted as interposedbetween the CES 1914, 1916 devices and the external communication device2326, although the CES 1914, 1916 devices may be directly coupled to theexternal communication device 2326, and/or the external communicationdevice 2326 may be coupled to a port of one of the network zones 1908,2322. The example of FIG. 23 depicts a transmitter/receiver 2328 thatperforms communication operations with external devices (e.g., a cloudserver, service tool, manufacturing tool, operator device, etc.). Incertain embodiments, the transmitter/receiver 2328 may be integratedwith the external communication device 2326, and/or more than onetransmitter/receiver 2328 may be present. Additionally or alternatively,multiple external communication access routes may be available, such asbut not limited to, a physical port access on one or more of the networkzones 1904, 1908, 2322, a WiFi transmitter/receiver, a Bluetoothtransmitter/receiver, etc.

The CND 1912 is depicted as a separate device, but may be positionedwith one or more of the network operating components 1916, 1914, 2308,2320, with a vehicle controller (not shown), and/or distributed acrossseveral devices. The example of FIG. 23 further includes a networkredundancy circuit 2202, depicted separately for convenience of thepresent description, that selectively provides a regulation controlcommand(s), providing for redundancy and data re-routing commands to thenetwork operating components 1916, 1914, 2308, 2320 responsive to adegradation or loss of a network zone and/or end point of a networkzone. An example operation of the network redundancy circuit 2202includes routing a communication from a first end point 2302 on thefirst network zone 1904 to a second end point 2304 on the second networkzone 1908 (e.g., during nominal operations), and changing the routingfrom the first end point 2302 on the first network zone 1904 to a thirdend point 2312 on the third network zone 2322 (e.g., in response to afailure or off-nominal operation of the second end point 2304).

An example operation of the CND 1912 includes providing for differentialpriority and/or permission access for a second end point 2304 on thesecond network zone 1908 relative to a third end point 2306 on thesecond network zone 1908, where the differential priority and/orpermission access relates to communications with the externalcommunication device 2326, storage of data (e.g., in a buffer, and/or ina memory storage on any device of the mobile application 1902), and/ordata communication throughput, collection rate, etc.

An example operation of the CEG 2308 includes an operation to performanalog/digital (A/D) processing of communications on the fourth networkzone 2324. For example, end point 2310 may be a sensor providing anelectrical signal representative of a sensed value, and/or an actuatorresponsive to an electrical signal from the CEG 2308. In certainembodiments, the end point 2310 may include more than one electricalsignal, such as a diagnostic signal, a heartbeat or status signal, etc.In certain embodiments, the CEG 2308 performs signal processing ofcommunications from the end point 2310, such as de-bouncing, filtering,saturation (e.g., reserving high or low values for diagnosticinformation), re-scaling, linearizing, or other operations. In certainembodiments, the CEG 2308 generates a processed payload of theelectrical signal, which may include one or more of: translating theelectrical signal into a sensed value (e.g., a pressure, a temperature,a speed, etc.), changing units of the sensed value (e.g., ° F. to K, orto ° C.), adjusting a bit depth of the sensed value (e.g., preparing a32-bit equivalent of a nominal 16-bit value provided by the end point2310 or a lookup table associated with the end point 2310), anormalization of the sensed value (e.g., providing a 0-1 value having anagreed meaning for the sensed parameter, and/or providing a voltageequivalent for a sensed voltage, such as when an algorithm operated on aa receiving end point such as 2314 on the third network zone 2322utilizes a different sensor having a different scaling, etc.), applyinga time shift to the sensed value (e.g., compensating for a sensorresponse time, network communication time, etc.), and/or converting asensed value between floating point and fixed point, and/or re-scaling afixed point value of the sensor. One of skill in the art, having thebenefit of the present disclosure and information ordinarily availablewhen contemplating an electrical signal based end point 2310 and a datarecipient end point (any other end point), can readily determine payloadprocessing operations to be performed that provide a configured payloadfor the recipient end point from the electrical signal provided by thecontemplated end point 2310. It will be understood that payloadprocessing may be performed in the reverse, for example taking anincoming payload from a communication and configuring an electricalsignal for the end point 2310 from the incoming payload (e.g., a commandto adjust an actuator, an electrical signal that may not be configuredfor the particular end point 2310, etc.). The example CEG 2308 furthergenerates a communication, for example to be provided at a port of theCES 1914, by providing a communication frame, encapsulating theprocessed payload, and having a protocol configured for the secondnetwork zone 1908 (in the example). In certain embodiments, the CEG 2308processes at least a portion of the frame of the communication, forexample by adjusting a time stamp (e.g., where the end point 2310provides a time stamp that is not configured properly for the mobileapplication 1902), applying a time stamp (e.g., where a time stamp isdesired, but the end point 2310 does not provide one), providing oradjusting a source indicator of the communication (e.g., where the endpoint 2310 does not have the capability to provide a source indicator,and/or utilizes a source indicator that is not configured properly forthe mobile application 1902), and/or providing or adjusting adestination indicator of the communication.

An example operation of the CEG 1916 includes processing a payload of acommunication from an end point device 1906, 2302, for example adjustingunits, and/or performing any other payload processing operations setforth in the present disclosure. An example operation of the CEG 1916includes encapsulating a payload of a communication from an end pointdevice 1906, 2302, and/or encapsulating all or a portion of a frame of acommunication from the end point device 1906, 2302 into a communicationhaving a protocol configured for the second network zone 1908 (in theexample). In certain embodiments, encapsulated portions of the frame ofthe communication from the end point device 1906, 2302 may additionallybe processed, for example to apply or adjust a time stamp, to apply oradjust a source indicator, and/or to apply or adjust a destinationindicator. In certain embodiments, the encapsulation of the frame orportions thereof, with or without processing, allow for communicationsbetween CAN devices, for example, on separate network zones, includingwhere one or more CAN devices is not coupled directly to a CAN network,but is interfacing through another end point (e.g., end point 2316 onthe third network zone 2322, which is an ethernet network in the exampleof FIG. 23).

In certain embodiments, the CEGs 1916, 2308 may share a port of the CES1914, and/or may be coupled to the second network zone 1908 utilizingseparate ports. Network zones of the mobile application may have anyselected topology, including, without limitation, a bus topology, aserial topology, a mesh topology, a hub topology, a ring topology,and/or a star topology. An example mobile application includes a firstnetwork zone provided as a first virtual local area network, and asecond network zone provided as a second virtual local area network. Inthe example, the first and second network zones may share networkphysical hardware and/or portions thereof.

Again referencing FIG. 23, an example system includes a first vehiclecontroller (e.g., end point 2302) on the first network zone 1904, asecond vehicle controller (e.g., end point 2304) on the second networkzone 1908, and a network redundancy circuit 2202 that selectivelyprovides a regulation control command, where the CND 1912 adjustsregulating communications between the first network zone 1904 and thesecond network 1908 zone in response to the regulation control command.Example and non-limiting regulation control commands include one or moreof: an off-nominal condition corresponding to the first vehiclecontroller 2302; a loss of a data element relating to the first vehiclecontroller 2302; and/or a lost control function of the first vehiclecontroller 2302. Example and non-limiting adjustments to the regulatingcommunications include one or more operations such as: providing analternate data element to the first vehicle controller 2302 (e.g., froma different end point that provides the same data, similar data, and/orback-up data); providing a data element corresponding to the lostcontrol function to the second vehicle controller 2304 (e.g., where thesecond vehicle controller 2304 is configured to perform backupoperations for all or a portion of the lost control function); and/orproviding a data value ordinarily available on the first network zone1904 to the second network zone 1908 (e.g., to provide the secondvehicle controller 2304 with data utilized to perform backup operationsfor all or a portion of the lost control function). An exampleadjustment to the regulating communications includes suppressing acommunication of a data value ordinarily available on the first networkzone 1904 (e.g., where the suppressed data value is no longer requiredon the first network zone 1904, and/or where the suppressed data valueis no longer indicated as valid data) in response to the lost controlfunction of the first vehicle controller 2302. The example systemincludes the CND 1912 providing the data value ordinarily available onthe first network zone 1904 to the second network zone 1908 (e.g., toprovide the data to the second vehicle controller 2304 to perform backupoperations for all or a portion of the lost control function) as aprocessed data value (e.g., to configure the data value for utilizationby the second vehicle controller 2304) to the second vehicle controller2304. The lost control function includes one or more or: a whole orpartial loss of a control function nominally performed by the firstvehicle controller 2302; a lost communication with an end point 1906 ofthe first network zone (e.g., an end point 1906 providing a data valueutilized to perform the lost control function); a loss of function ofthe first vehicle controller 2302 (e.g., due to a fault code, failurecondition, and/or invalid communications provided by the first vehiclecontroller 2302); and/or a loss of communication with the first vehiclecontroller 2302.

The example system includes the first vehicle controller 2302 positionedin a first risk exposure profile, and the second vehicle controller 2304positioned in a second risk exposure profile, where the first riskexposure profile is distinct from the second risk exposure profile.Example and non-limiting distinctions between the risk exposure profilesinclude one or more of: a geometric distinction; an environmentaldistinction; a failure mode distinction; a likely risk type distinction;and/or a likely disturbance distinction.

Certain alternative and/or additional regulation control commandsprovided by the network redundancy circuit 2202 include one or more of:an off-nominal condition corresponding to the first network zone 1904; aloss of communication between at least one end point 1906 of the firstnetwork zone and the first network zone 1904; a physical failure of atleast a portion of the first network zone 1904; and/or a bandwidthlimitation of the first network zone 1904. Example and non-limitingadjustments to the regulating communications include one or more of:routing at least one communication from the first network zone 1904 tothe second network zone 1908; repeating at least one communication fromthe first network zone 1904 to the second network zone 1908; shifting atleast one end point (e.g., 1906) from the first network zone 1904 to thesecond network zone 1908; shifting and/or repeating relevantcommunications with the at least one end point (e.g., 1906) from thefirst network zone 1904 to the second network zone 1908; and/or shiftingand/or repeating relevant communications with the at least one end point(e.g., 1910) from the second network zone 1908 to the first network zone1904 (e.g., utilizing the end point 1910 as an alternate data source fora lost end point 1906 of the first network zone 1904). Operations aredescribed between the first network zone 1904 and the second networkzone 1908 for purposes of illustration, but operations may be performedbetween the first-second network zone, first-third network zones, and/orsecond-third network zones. Additionally or alternatively, certainoperations (e.g., shifting an end point from one network zone toanother) imply that an associated end point is movable between networkzones, which may be available in circumstances that will be understood,but include at least: where the end point is coupled or couplable tomore than one network zone, where the end point is reconfigurable toprovide valid communications to more than one network zone (e.g., wherethe end point can detect network protocols, frame configurations, etc.,and/or where the end point is responsive to commands from the networkredundancy circuit 2202 and/or CND 1912 to adjust network protocols,frame configurations, etc.), where the network zones are compatible(e.g., consistent protocols, frame configurations, etc., and/or capableto communicate utilizing some variability of protocols, frameconfigurations, etc.), and/or where the network zones are separatevirtual local area networks (e.g., where separation between therespective network zones is at least partially logical rather thanphysical).

In certain embodiments, the CND 1912 may be co-located, and/or haveportions co-located with one or more vehicle controllers (not shown) ofthe system. For example, reference FIG. 15 and the related descriptions.The example system includes a vehicle controller 2302 on the firstnetwork zone 1904, a first portion of the CND 1912 co-located with thevehicle controller 2302, where the first portion of the CND 1912includes non-transient computer readable instructions configured to,when executed by a process of the vehicle controller 2302, perform atleast a portion of the operations of regulating the communications.

In certain embodiments, the CND 1912 includes a portion co-located witha vehicle controller (not shown), where the portion of the CND includesan ethernet switch (e.g., 1914), where a network zone 1908 includes anethernet network, where communications between end points of the networkzone 1908 and another network zone 1904 are routed through the ethernetswitch 1914 (e.g., with CEG 1916 providing communications from networkzone 1904 through a port of the CES 1914), and where the ethernet switch1914 is positioned within a housing with the vehicle controller, and/orpositioned on a same board with the vehicle controller.

In certain embodiments, the CND 1912 includes a portion co-located witha vehicle controller (not shown), where the portion of the CND includesa CEG (e.g., 1916), where a network zone 1904 includes an ethernetnetwork, where communications between end points of the network zone1904 and another network zone 1908 are routed through the CEG 1916(e.g., with CEG 1916 providing communications from network zone 1904through a port of the CES 1914 to network zone 1908), and where the CEG1916 is positioned within a housing with the vehicle controller, and/orpositioned on a same board with the vehicle controller.

An example system includes a second vehicle controller 2304 on thesecond network zone 1908, where the CND 1912 includes a first portionco-located with a vehicle controller (not shown), and a second portionco-located with the second vehicle controller 2304. Each of the firstportion or second portion of the CND 1912 may include one or more of: aCES, a CEG, and/or non-transient computer readable instructionsconfigured to, when executed by a process of the respective vehiclecontroller (e.g., vehicle controller and/or second vehicle controller2304), perform at least a portion of the operations of regulating thecommunications between network zones 1904, 1908 (and/or 2322, 2324).Each of the first portion or the second portion of the CND 1912 may bepositioned within a housing of the respective vehicle controller, and/orpositioned on a same board with the respective vehicle controller.

Certain aspects of the present disclosure are set forth as procedures toperform operations related to the present disclosure. Operations may beperformed, without limitation, by any controllers, circuits, devices,components, sensors, actuators, logic circuits, or other aspects as setforth in the present disclosure. Procedures are depicted schematicallyas illustrative examples, and operations may be omitted, combined,divided, and/or re-ordered in whole or part. In certain embodiments, oneor more operations of a first procedure may be combined with one or moreoperations of another procedure.

Referencing FIG. 24, a schematic flow diagram of a procedure 2400 forregulating inter-network communications (e.g., between distinct networkzones of a mobile application) is schematically depicted. The exampleprocedure 2400 includes an operation 2402 to regulate inter-networkcommunications (e.g., as referenced throughout the present disclosure,including at least with reference to FIG. 19 and the relateddescription) between a first network (and/or network zone) and a secondnetwork (and/or network zone) of a mobile application. The exampleprocedure 2400 further includes an operation 2404 to determine whetheran off-nominal condition is present, where the off-nominal conditionincludes, without limitation, a condition of any network, an end point,a controller, and/or a control function. In response to operation 2404determining TRUE, the procedure 2400 includes an operation 2406 toadjust the regulating of the inter-network communications. Withoutlimitation to any other aspect of the present disclosure, operation 2406to adjust the regulating of the inter-network communications include anyone or more of the following: routing a communication from a firstnetwork to a second network; repeating, sharing, or mirroring acommunication nominally on a first network additionally onto a secondnetwork; shifting an end point from a first network to a second network;suppressing a communication on one of the networks; adjusting a datasampling rate and/or communication rate of a communication and/or endpoint on one of the networks; adjusting control operations, at least inpart, from a first controller on the mobile application to a secondcontroller on the mobile application, and/or providing the secondcontroller with data nominally provided to the first controller, and/orwith alternate data determined in response to the adjusted controloperations; and/or providing a communication to a controller on themobile application from an alternate data source.

Referencing FIG. 25, a schematic flow diagram of a procedure 2500 forencapsulating and/or processing communications from a first network forcommunication onto a second network for a mobile application (e.g.,communications between end points on separate network zones) isschematically depicted. The example procedure 2500 includes an operation2502 to receive a first network communication (e.g., a communicationprovided by any end point on any network zone of a mobile application),an operation 2504 to process, remove, or include non-payload frameinformation of the communication (e.g., metadata, identifiers, timestamps, and/or any other information of the communication that is notthe payload, or base data, for the communication). The example procedure2500 further includes an operation 2506 to process, remove, or includepayload frame information from the communication (e.g., removing thepayload, for example where the communication is utilized for reasonsother than the payload, such as in network monitoring operations; and/orchanging the payload units, resolution, bit depth, data type, etc.), andan operation 2508 to encapsulate the communication for communicationonto a second network of the mobile application. The example procedure2500 further includes an operation 2510 to provide the encapsulatedcommunication as a second network communication on a second network ofthe mobile application. In certain embodiments, procedure 2500 providesfor operations to provide messages between end points on separatenetworks having incompatibilities (e.g., network protocols, messagecharacteristics, network addressing, etc.), and/or between end pointshaving otherwise incompatible data usage (e.g., payload units, datatypes, bit depths, etc.). In certain embodiments, operations ofprocedure 2500 allow for encapsulation of messages from a first network(e.g., a CAN network) to a second network (e.g., an ethernet network),and/or to tunnel messages from a first network having a first networktype to another network having the first network type, by passingthrough an intermediary network having a second network type.

Referencing FIG. 26, an example procedure 2600 for providing up-sampledand/or down-sampled communications from an end point on a network of amobile application is schematically depicted. The example procedure 2600includes an operation 2602 to determine an up-sampling and/ordown-sampling scheme for a communication (e.g., from a first network).Example operations 2602 include, without limitation to any other aspectof the present disclosure, determining the up-sampling and/ordown-sampling scheme in response to a requested data rate for thecommunication, a data capability rate for a network and/or for a sourceend point for the communication, a data storage value for a device inthe system (e.g., a communication buffer storage, and/or a long-termdata storage location), and/or a priority for the communication (e.g.,relative to competing communications, according to operating conditionsfor the mobile application, and/or according to a related priority for aflow, end point, vehicle function, or the like).

The example procedure 2600 further includes an operation 2500 to preparesecond network communications (e.g., reference FIG. 25 and procedure2500), including, for example, processing payload and/or non-payloadinformation of the communications, and encapsulating the (processed orunprocessed) payload and/or non-payload information into a communicationprepared for the second network.

The example procedure 2600 further includes an operation 2604 toup-sample and/or down-sample the second network communications. Withoutlimitation to the general notion that all operations for proceduresdescribed herein can be re-ordered, divided, omitted, and/or combined,operations 2500 and 2604 of procedure 2600 may be performed in anyorder, including iteratively, simultaneously, and/or progressivelytogether, as it will be understood that up-sampling and/or down-samplingoperations 2604 may render operation 2500 unnecessary for certaincommunications (e.g., an excluded down-sampled communication, and/orexcluded spanning or non-spanning communications) and/or operations 2604may create payloads and/or non-payload information for communications(e.g., added up-sampled communications, and/or added spanning ornon-spanning communications) that are then prepared in operation 2500.Without limitation to any aspect of the present disclosure, operation2604 may include any operations described in relation to FIGS. 17 and18, and the related description. The example procedure 2600 furtherincludes an operation 2606 to provide the up-sampled and/or down-sampledcommunications to the second network. Operations for procedure 2600 arerecited in terms of providing communications from an end point on afirst network to an end point on a second network for clarity of thepresent description, but it will be understood that procedure 2600 isapplicable to any communications on a mobile application, includingpublished communications for a data service (e.g., reference FIG. 27 andthe related description), communications passed to an external device,and/or communications within a same network (e.g., from a first endpoint on a first network to a second end point on the second network).

Referencing FIG. 27, an example apparatus 2700 for providing a serviceoriented architecture for a mobile application having a mixed networkenvironment is schematically depicted. The example apparatus 2700includes a vehicle data service definition circuit 2702 that interpretsa service availability description 2710 including available data valuesfrom end point(s) 1906, 1910 on network(s) 1904, 1908 of a vehicle. Forexample, the vehicle data service definition circuit 2702 may receivecommunications from end point(s) 1906, 1910 that provide an indicatorthat one or more data values are available for communication, and/orread an indicator from a configuration file 2718 (depicted as a datastore in the example of FIG. 27) of data values available forcommunication. The service availability description 2704 may include anytype of data value available on the vehicle, including sensed values,actuator feedback values (e.g., position, state, fault values, etc.),parameters from any controller in the system, virtual sensor values,control parameters (e.g., set points, reference points, determined statevalues, reference error values, etc.), and/or stored values (e.g.,accumulated parameters, snapshot information, calibrations, etc.). Aservice availability description 2704 may be associated with a singleend point, a group of end points, a flow, or any other data provider orgroup of data providers in the system. The data associated with aservice availability description 2704 may be a raw data value and/or aprocessed version of a data value (e.g., a filtered, low sampling rate,time lagged data, etc.).

The example apparatus 2700 further includes a vehicle data servicemanagement circuit 2706 that publishes a data service availability value2708 in response to the service availability description 2704. Incertain embodiments, the data service availability value 2708 mayinclude the same data, or a formatted version of the data, as providedby the service availability description 2704. In certain embodiments,the data service availability value 2708 may include a redacted oradjusted version (e.g., fewer parameters, reduced data rates, reducedresolution, etc., than provided in the service availability description2704) of the service availability description 2704, for example when adevice providing the service availability description 2704 does not havefull permissions (e.g., as determined from configuration file 2718) topublish all of the listed parameters, to publish at the planned datarates, and/or to publish with the indicated sampling rates. In certainembodiments, the vehicle data service management circuit 2706 determinesthat a publishing device (and/or end point, flow, etc.) does not havepermissions to provide a service advertised in the service availabilitydescription 2704, and accordingly the vehicle data service managementcircuit 2706 does not provide a corresponding data service availabilityvalue 2708 for that service availability description 2704. In certainembodiments, the vehicle data service management circuit 2706 determinesthat certain data service availability values 2708 are restricted toonly certain subscribing devices, and accordingly configures the dataservice availability value 2708 (e.g., applying tags, encryptionschemes, metadata, or the like) such that unauthorized devices areunable to see the corresponding data service availability value 2708and/or are unable to subscribe to the corresponding data serviceavailability value 2708. The example vehicle data service managementcircuit 2706 generates a data service value description 2709 in responseto a subscription request 2710 to the data service availability value2708, and data values from end point(s) 1906, 1910. For example, thedata service value description(s) 2709 describe parameters to becollected, grouped, and/or processed, and may further include end pointdescriptions, etc. The data service value description(s) 2709 providecollection parameters utilizable by the CND 1912 to support the serviceshaving active valid subscriptions, and further allows for management ofcollection operations, such as screening of authorized data accessand/or consolidation of redundant parameters (e.g., where more than oneservice may provide a same data element as a part of the service, wheremultiple data rates for a parameter can be serviced with a single highrate collection operation, etc.).

The example apparatus 2700 includes a CND 1912 that performs operationsto regulate communications between networks 1904, 1908 of the vehicle.In the example apparatus 2700, the circuits 2702, 2706 are depicted asbeing positioned with the CND 1912 for clarity of the depiction, but itwill be understood that one or more of the components, circuits,communication flows, data elements, and/or other aspects depicted inFIG. 27 may be distributed across devices in the system. The example CND1912 includes a regulation circuit 2710 (e.g., which may include and/orbe in communication with network operation components such as a CES,CEG, or other operational component) that regulates communicationsbetween the first network 1904 and the second network 1908, and thatgenerates a data service value 2712 in response to the data servicevalue description(s) 2709 and data values from the end point(s), andpublishes the data service value(s) 2712 in response to the data servicevalue description(s) 2712.

An example regulation circuit 2710 collects the data from end pointsdirectly, and publishes the data as a broadcast (e.g., visible to allend points) and/or multi-cast (e.g., provided to subscribing end points)parameter, for example according to permissions, network capacity,importance and/or usage breadth of the parameter, etc. In certainembodiments, the example regulation circuit 2710 provides the dataservice value(s) 2712 to a service broker 2714 that managescommunication of the data service value(s) 2712 to subscribing endpoints or devices. An example embodiment having a service broker 2714additionally or alternatively utilizes the service broker 2714 tocommunicate the data service availability value(s) 2708 to end points ordevices, and/or to receive subscription request(s) 2710 from devices. Incertain embodiments, the vehicle data service management circuit 2706communicates with the service broker 2714 to determine the subscriptionrequest(s) 2710. In certain embodiments, the vehicle data servicemanagement circuit 2706 receives subscription request(s) from end pointdevices on a network 1904, 1908.

An example apparatus 2700 includes the vehicle data service managementcircuit 2706 and/or the service broker 2714 receiving subscriptionrequest(s) 2710 from an external device, such as a service device 2716.In the example, the vehicle data service management circuit 2706determines data service value description(s) 2709 responsive to thesubscription request(s) 2710 from the external device (e.g., includingdetermining permissions, etc.), and the external device receivesparameters according to the subscribed service, as with subscribingon-vehicle end points, devices, flows, and the like.

In certain embodiments, the service availability description 2704further includes an authorization description (e.g., when the end pointand/or device publishing the service availability applies a permissionlevel), and the vehicle data service management circuit 2706 furtherlimits publication of the data service availability value 2708, and/orlimits acceptance of a corresponding subscription request 2710,responsive to the authorization description. Additionally oralternatively, the vehicle data service management circuit 2706 maydetermine the authorization description from the configuration file2718. An example vehicle data service management circuit 2706 limitspublication of the data service availability value (and/or limitsacceptance of a corresponding subscription request 2710) in response toone or more of: an end point identifier of the subscription requestor;an application identifier (e.g., motive power management; entertainmentmanagement; climate control; stability control; etc.) of thesubscription requestor; a flow identifier of the subscription requestor;a user identifier (e.g., an identity of a service technician, apersonnel role associated with the requesting device, application, flow,etc.) of the subscription requestor; and/or an entity identifier (e.g.,an entity name, entity role, manufacturer, OEM, service entity, ownerentity, operator entity, third-party entity, etc.) of the subscriptionrequestor.

An example vehicle data service definition circuit 2702 furtherinterprets a service availability value 2720, and updates the serviceavailability description 2704 in response to the service availabilityvalue 2720. For example, the service availability value 2720 may providean indication that the published service is unavailable, such as duringcertain operating conditions, due to a fault or failure of an end pointor device providing the data for the service, due to a change inpermissions of the system (and/or a conditional permission where thepermission criteria are not currently met), due to the service appearingin the configuration information 2718 but referencing end points,devices, applications, flows, or the like that are not present on thevehicle, an expiration of a permission, etc. In a further example, theservice availability value 2720 further includes an authorizationdescription, where the vehicle data service definition circuit 2702limits updating of the service availability description 2704 in responseto the authorization description. An example vehicle data servicemanagement circuit 2702 limits updating of the service availabilitydescription in response to one or more of: an end point identifier ofthe service availability value provider; an application identifier ofthe service availability value provider; a flow identifier of theservice availability value provider; a user identifier of the serviceavailability value provider; and/or an entity identifier of the serviceavailability value provider. An example vehicle data service definitioncircuit 2702 receives a service availability value 2704 from a datacollection management device external to the vehicle (e.g., but notlimited to, the service device 2716). Accordingly, the apparatus 2700allows for provision and updating of services by external devices, suchas utilized by an operator, owner, service entity, manufacturing entity,third-party applications, fleet owner, etc., including (depending uponpermissions) updating the configuration information, intra-vehiclepermissions, etc.

Referencing FIG. 28, an apparatus 2800 for encapsulating networkcommunications to support moving communications between mixed networkson a mobile application is schematically depicted. The example apparatus2800 includes a first network interface circuit 2802 that interprets afirst network data set 2804 (e.g., messages from end points on a firstnetwork 2805) having a first network format 2806 (e.g., protocols,message parameters, beginning and/or terminating bits or information,payload formatting, message types, message confirmation protocols,and/or network layers), and a translation circuit 2808 that determines amessage value 2810 from the first network data set 2804, and encodes themessage value 2810 in a second network data set 2812 having a secondnetwork format 2814. A message data set, as used herein, should beunderstood broadly, and may include a single message, a group of relatedmessages, a group of messages present on an associated network over aperiod of time, operating condition, or the like. A message value, asutilized herein, includes any selected aspects of a message, including apayload, a frame, portions of a frame, metadata, or the like.

The example apparatus 2800 further includes a second network interfacecircuit 2816 that transmits the second network data set 2812 (e.g., as amessage to a second network 2817). The apparatus 2800 includes the firstnetwork interface circuit 2802, the translation circuit 2808, and thesecond network interface circuit 2816 defined by either a single device,or by two devices, with the first device and/or two devices capable tobe incorporated into a vehicle. For example, a CND may include all ofthe first network interface circuit 2802, the translation circuit 2808,and the second network interface circuit 2816. In another example, a CEGmay include the first network interface circuit 2802 and the translationcircuit 2808, and a CES may include the second network interface circuit2816. In another example, a CEG may include the first network interfacecircuit 2802, and a CES may include the translation circuit 2808 and thesecond network interface circuit 2816. In another example, a CEG mayinclude all of the first network interface circuit 2802, the translationcircuit 2808, and the second network interface circuit 2816.

In the example of FIG. 28, the first network format 2806 is distinctfrom the second network format 2814 in at least one aspect. An exampleapparatus 2800 includes one of the first network format 2806 or thesecond network format 2814 as a CAN network. An example apparatus 280includes the first network format 2806 as a CAN network, and the secondnetwork format 2814 as an ethernet network.

An example apparatus 2800 further includes a configuration circuit 2818that modifies the first network interface circuit 2802, the translationcircuit 2808, and/or the second network interface 2816 in response to aconfiguration command value 2820. Example and non-limiting configurationcommand values 2820 include one or more of: which messages of the firstnetwork data set 2804 are to be communicated to the second network;up-sampling and/or down-sampling operations to be performed on messagesof the first network data set 2804; translation parameters fordetermining the message value 2810 (e.g., which aspects of the messagesuch as the payload, frame portions, metadata, etc. are to be consideredthe message value 2810) and/or encoding the message value into thesecond network data set 2812 (e.g., encapsulation operations, sourceand/or destination identifiers, unit conversions, etc.); and/or networkregulation operations (e.g., reference FIG. 19 and the relateddescription). An example configuration circuit 2818 is defined by thefirst device, or by the second device (optionally, and if present), suchas a CND, CEG, and/or CES. In certain embodiments, the configurationcircuit 2818 further selectively configures which of one or moreportions of the first network interface circuit 2802, the translationcircuit 2808, and/or the second network interface circuit 2816 aredefined by the first device and/or the second device (e.g., allowing theconfiguration circuit 2818 to adjust operations between devices, torepurpose a device such as a CEG or CES, and/or to shift networkoperation and/or regulation functions in response to system changes,topology changes, and/or off-nominal operating conditions). In certainembodiments, the configuration circuit 2818 receives a configurationcommand value 2820 from a CND, from an external device, and/or byaccessing a configuration file.

Referencing FIG. 29, an apparatus 2900 for mirroring a port, providingcommunications from a first network to a second network on a mobileapplication, is schematically depicted. The example apparatus 2900includes a first network interface circuit 2802 having a number of ports2902 that interpret first communications data 2904 of first network 2805onboard a vehicle. The ports 2902 may be physical ports, logical ports,and/or a combination of physical and logical ports. The exampleapparatus 2900 includes a second network interface circuit 2816 thatinterprets second communications data 2906 from a second network 2817onboard the vehicle. The second network 2817 is of a different type thanthe first network 2805 (e.g., a CAN network versus an ethernet network,networks having distinct network formats 2806, 2814, and/or any othertype difference as set forth herein and/or understood in the art). Theapparatus 2900 further includes a translation circuit 2808 that relaysthe second communications data 2906 (e.g., which may include processing,encapsulating, and/or otherwise configuring the second communicationsdata 2906 for communication on the first network 2805) to the firstnetwork interface circuit 2802 for transmission on the first network2805 via at least one of the ports 2902. An example first networkinterface circuit 2802 mirrors a first port of the ports 2902 to asecond port of the ports 2902, for example allowing an external device2908, data collection operation (not shown), and/or other device in thevehicle to observe and/or take data from the second port therebyreceiving data that is the same as the data communicated at the firstport. Without limitation to any other aspect of the present disclosure,the port mirroring operation allows for network monitoring operations,data collection of any parameter from any end point of a network in thevehicle (e.g., without requiring knowledge of the requesting deviceabout the network configuration, communication protocols, and/orposition of end points distributed throughout the vehicle).

An example apparatus 2900 further includes a configuration circuit 2818that interprets a port selection command value 2820, and assigns whichports 2902 are the first port and the mirrored port. Accordingly, theconfiguration circuit 2818 can provide communication values from any ofthe ports 2902, which may include any selected end points on the firstnetwork 2805, and/or may include all of the second communications data2906 (e.g., where the translation circuit 2808 relays the secondcommunications data 2906 to a single one of the ports 2902), to theselected mirrored port. In certain embodiments, the configurationcircuit 2818 receives the port selection command value 2820 from a CND,from a configuration file, and/or from a requesting external device 2908(e.g., a service tool, OBD device, vehicle and/or network monitoringdevice, etc.), and/or from any controller on the vehicle havingsufficient permissions to provide a port selection command value 2820.

An example configuration circuit 2818 interprets a port assignmentcommand value 2820 identifying: an assigned port and a device (e.g., anend point, controller, flow, application, etc.) on the second network2817, portions of the second communications data 2906 corresponding tothe identified device, and transmits (and/or commands the first networkinterface circuit 2802 to perform the transmitting) the identifiedportions of the second communications data 2906 to the assigned port. Incertain further embodiments, the device on the second network 2817 mayadditionally or alternatively include communications data on othernetworks (e.g., the first network 2805, such as when an application,flow, or other device on the second network 2817 includes aspectsoperating on other networks) corresponding to the identified device, andthe operations of the configuration circuit 2818 and first networkinterface circuit 2802 further support providing the correspondingcommunications data from all related networks at the assigned port.

Referencing FIG. 30, an apparatus for controlling intra-network trafficon a mobile application is schematically depicted. The example apparatus3000 includes a first network interface circuit 2802 that interpretsfirst communications data 2904 of a first network 2805 onboard avehicle, and a second network interface circuit 2816 that interpretssecond communications data 2906 of a second network 2817 onboard thevehicle. The second network 2817 is of a different type than the firstnetwork 2805 (e.g., a CAN network versus an ethernet network, networkshaving distinct network formats 2806, 2814, and/or any other typedifference as set forth herein and/or understood in the art). Theexample apparatus 3000 further includes a translation circuit 2808 thatselectively relays first communications data 2904 to the second networkinterface circuit 2816 for transmission on the second network 2817,and/or second communications data 2906 to the first network interfacecircuit 2802 for transmission on the first network 2805. The exampletranslation circuit 2808 further configures the messages from eachnetwork for the other network, for example processing, encapsulating,and/or otherwise configuring the messages before relaying the messages.The example apparatus 3000 further includes a regulation circuit 3002that regulates the second network interface circuit 2816, the firstnetwork interface circuit 2802, and/or the translation circuit 2808,including, without limitation, performing any one or more operationssuch as regulating operations described in relation to FIG. 19 and therelated description. An example regulation circuit 3002 restricts anamount of the first communications data 2904 relayed to the secondnetwork interface circuit 2816, and/or an amount of the secondcommunications data 2906 relayed to the first network interface circuit2802. An example regulation circuit 3002 restricts an amount ofcommunications data by limiting a data rate (e.g., an amount of data perunit time, and/or an amount of data over a period of time), by limitingan amount of data based on a saturation rate (e.g., utilization ofavailable bandwidth, utilization of a portion of bandwidth permitted forthe related communications, etc.), limiting an amount of data based on astorage capacity, based upon a capability of a receiving device (e.g.,an end point on one of the networks), and/or based upon a requested datarate of a receiving device.

An example regulation circuit 3002 restricts transmission of one or moreportions of the first communications data 2904 and/or the secondcommunications data 2906, for example restriction transmission of datacorresponding to selected end points, flows, applications, and/oraccording to an operating condition of the vehicle, an off-nominalcondition of a network and/or end point, or the like. In certainembodiments, combinations of these restrictions may be present—forexample where a specified vehicle operating conditions indicates thattransmissions to or from certain end points are to be restricted, and/ortransmissions related to certain data flows are to be restricted.Restriction operations include, without limitation to any other aspectof the present disclosure, include operations such as: limitingcommunications, limiting communication rates, suppressing communications(at least for a time period and/or during certain operating conditions),performing down-sampling on certain messages (e.g., reducingcommunicated message traffic), and/or performing up-sampling on certainmessages (e.g., which may shift operational workloads betweencomponents, including reducing the workload of some components, such asutilizing up-sampling to reduce an actual data sampling rate, performingup-sampling to generate configured messages to reduce encapsulationworkloads, and the like). In certain embodiments, restriction operationsof the regulation circuit 3002 include considering associated priorityinformation for messages, end points, flows, networks, or the like,and/or prioritizing portions of the relayed first communications data2904 and/or second communications data 2906.

Referencing FIG. 31, an apparatus to support configurable network statusmonitoring for a mobile application having a mixed network isschematically depicted. The example apparatus 3100 includes a firstnetwork interface circuit 2802 that interprets a first communicationsdata 2904 of a first network 2805 onboard a vehicle, and a secondnetwork interface circuit 2816 that interprets a second communicationsdata 2906 of a second network 2817 onboard the vehicle. The secondnetwork 2817 is of a different type than the first network 2805 (e.g., aCAN network versus an ethernet network, networks having distinct networkformats 2806, 2814, and/or any other type difference as set forth hereinand/or understood in the art). The example apparatus 3100 furtherincludes a network status circuit 3102 that generates network statusdata 3106 by monitoring portions of the first communications data 2904and/or second communications data 2906. In the example of FIG. 31, thenetwork status circuit 3102 is depicted in communication with a port2902 of the first network interface circuit 2802 to collect the networkstatus data 3106, but it will be understood that the network statuscircuit 3102 may be positioned at other locations in the system, and maycollect network status data 3106 from the translation circuit 2808, thesecond network interface circuit 2816, and/or may access the networkstatus data 3106 as stored data on a memory storage of the apparatus3100.

The example apparatus 3100 further includes a configuration circuit 2818that configures at least one of the ports 2902 to mirror at leastanother one of the ports 2902, for example to provide the network statusdata 3106 at selected ports 3902 of the first network interface circuit2802. An example configuration circuit 2818 interprets a port assignmentcommand value 3104 that identifies the selected port (e.g., to providethe network status data 3106), and further identifies portions of thefirst communications data 2904 and/or second communications data 2906(e.g., based on monitored devices, networks, end points, flows, etc.),and transmits (and/or command the first network interface circuit 2802)to communicate the identified portions of the communications to theselected port. An example apparatus 3100 includes the configurationcircuit 2818 that modifies the network status data 3106, for exampleresponsive to selected devices, end points, flows, applications,controllers, networks, a system of the vehicle, or the like. An exampleapparatus 3100 includes the configuration circuit 2818 modifying thenetwork status data 3106 in response to a data selection command value3108 (e.g., provided by the network status circuit 3102, a CND, anexternal device, a configuration file, and/or other controller orcomponent of the system), and adjusting data provided to the selectedport (or otherwise to the network status circuit 3102) responsive to thedata selection command value 3108. In certain embodiments, the dataselection command value 3108 additionally or alternatively identifiesone or more protocols (e.g., data collection rates, time values and/orranges, selected processing, selected portions of message frames,metadata, a protocol type such as TCP, UDP, AVB, etc.). The exampleapparatus 3100 depicts the circuits 2802, 2808, 2816, 2818 positionedwithin a same housing 3110, and the network status circuit 3102separated from the housing 3110 (e.g., as an external device), in anon-limiting example. The example apparatus 3100 may include thecircuits 2802, 2808, 2816, 2818 and/or sub-groups of the circuits 2802,2808, 2816, 2818 positioned on a same circuit board.

With further reference to FIG. 31, an example first network 2805 is anethernet network, and an example second network 2817 is a CAN network.In the example, the translation circuit 2808 is interposed between thefirst and second network interface circuits 2802, 2816, and translatesethernet communications data into CAN communications data, and/or CANcommunications data into ethernet communications data. The networkstatus circuit 3102 generates the network status data 3106 by monitoringethernet communications data 2904 and/or CAN communications data 2906.In certain embodiments, the network status data 3106 is based at leastin part on one or more of: a bandwidth across the translation circuit2808; a number of messages in the ethernet and/or CAN communicationsdata having an address corresponding to a same device, a sameapplication, and/or a same flow; and/or a number of communication errors(e.g., dropped packets, delay events, bad checksums, invalid data,failed handshakes or acknowledgements, etc.).

Referencing FIGS. 32-34, example arrangements of apparatuses forregulating communications between networks on a mobile applicationhaving mixed networks are depicted for illustration.

Referencing FIG. 32, an example arrangement includes a CEG 3206 (e.g., aconfigurable edge gateway, and/or a CAN gateway) having a first networkinterface circuit 2802 that communicates with a CAN network 3202, and atranslation circuit 2808 that passes selected messages between the CANnetwork 3202 and a port of a second network interface circuit 2816. Theexample arrangement includes a CES 3208 that includes the second networkinterface circuit 2816 that communicates with an ethernet network 3204,and includes a configuration circuit 2818 that performs operations toregulate communications between the networks 3202, 3204. The arrangementof FIG. 32 may form all or a portion of a CND as set forth throughoutthe present disclosure, and/or may perform operations to regulatecommunications between the networks 3202, 3204 responsive to CNDcommands, where the CND is distributed elsewhere in the system.

Referencing FIG. 33, an example arrangement is depicted that may formall or a portion of a CND as set forth throughout the presentdisclosure, and/or may perform operations to regulate communicationsbetween the networks 3202, 3204 responsive to CND commands, where theCND is distributed elsewhere in the system. The example of FIG. 33 isdistinct from the example of FIG. 32, where the translation circuit 2808is positioned with the CES 3208, and receives CAN messages directly fromthe first network interface circuit 2802.

Referencing FIG. 34, an example arrangement is depicted that may formall or a portion of a CND as set forth throughout the presentdisclosure, and/or may perform operations to regulate communicationsbetween the networks 3202, 3204 responsive to CND commands, where theCND is distributed elsewhere in the system. The example of FIG. 34 isdistinct from the example of FIG. 33, where the configuration circuit2818 is distributed between the CES 3208 and the CEG 3206. In theexample of FIG. 34, one of the configuration circuits 2818 may be aprimary, passing configuration information to the other one of theconfiguration circuits 2818. In certain embodiments, each configurationcircuit 2818 may operate independently, for example receivingconfiguration information from a configuration file, throughcommunications with a CND, or the like. The examples of FIGS. 32-34 arenon-limiting illustrations to depict certain aspects and arrangements ofthe present disclosure.

Referencing FIG. 35, an example procedure 3500 to provide a serviceoriented architecture for a vehicle having a mixed network isschematically depicted. The example procedure 3500 includes an operation3502 to interpret a service availability description, the serviceavailability description comprising available data values from a firstend point device on one of a first network or a second network of avehicle, an operation 3504 to publish a data service availability valuein response to the service availability description, an operation 3506to generate a data service value description in response to asubscription request to the data service availability value, anoperation 3508 to generate a data service value in response to the dataservice value description and data values from the first end pointdevice, and an operation 3510 to publish the data service value inresponse to the data service value description. An example operation3510 to publish the data service value includes providing the dataservice value to second end point device, for example an end pointdevice on another network from the first end point device. An exampleoperation 3510 further includes publishing the data service value byproviding network communications to subscribing end point devices, eachof the subscribing end point devices on one of the first network or thesecond network, and wherein the network communications comprise thegenerated data service value. An example data service availability valueincludes a name for a service, a list of data parameters provided by theservice, a list of available commands provided by the service, etc.(e.g., from providing devices to a CND), and the data service valuedescription includes a name for a service, a list of data parametersprovided by the service, a list of available commands provided by theservice, etc. (e.g., from the CND to potential subscribing devices),where the data service value description may match the data serviceavailability value, or may be configured differently from the dataservice availability value (e.g., simplified, enhanced, standardized,etc.). An example data service value includes data values correspondingto a data service availability value.

In certain embodiments, the procedure 3500 further includes an operation3512 to receive subscription requests from end point devices on both thefirst network and the second network. An example operation 3512 includesreceiving a subscription request from a device external to the vehicle,such as a service device, web application, cloud-based application,and/or third party application, where operations 3508 and/or 3510 areperformed in response to operation 3512 (e.g., only generating the dataservice value and/or publishing the data service value where asubscribing device is available for the service). An example procedure3500 includes the service availability description further including anauthorization description, where operation 3504 includes limitingpublication of the data service availability value in response to theauthorization description (e.g., where unauthorized devices cannot seethe data service). An example operation 3504 includes limitingpublication of the data service availability value in response to anidentifier of the subscription requestor (e.g., an end point, flow,vehicle function, application, service group, and/or an entityassociated with any of these).

An example procedure 3500 includes the service availability descriptionfurther includes an authorization description, where operation 3510includes limiting publication of the data service value in response tothe authorization description (e.g., not allowing a subscription to thepublished service). An example operation 3510 includes limitingpublication of the data service value in response to an identifier ofthe subscription requestor (e.g., an end point, flow, vehicle function,application, service group, and/or an entity associated with any ofthese).

An example operation 3502 includes interpreting a service availabilityvalue, and updating the service availability description in response tothe service availability value. For example, the service availabilityvalue may be updated by a providing device (e.g., an end point, flow,vehicle function, application, service group, external device, etc.)and/or may be updated by a change in the policy adding a service to theavailable services, and/or removing a service from the availableservices. An example operation 3502 further includes limiting theupdating of the service availability description in response to theauthorization description (e.g., verifying an authorization of theupdating device before updating the service availability description),and/or in response to an identifier of the updating device.

Referencing FIG. 36, an example procedure 3600 to provide messagesbetween networks for a vehicle having a mixed network is schematicallydepicted. The example procedure 3600 includes an operation 3602 tointerpret a first network data set having a first network format, anoperation 3604 to determine a message value from the first network dataset in response to operation 3602, an operation 3606 to encode themessage value in a second network data set having a second networkformat, and an operation 3608 to transmit the second network data set(e.g., onto the second network). An example procedure 3600 includes thenetworks having vehicle data formats, where the vehicle data formats aredifferent formats (e.g., CAN, MOST, LIN, FlexRay, TTP, LVDS, AVB, and/orelectrical signal formats). An example first network format is a CANbased format, and an example second network format is an ethernet basedformat. An example procedure 3600 further includes an operation 3610 tointerpret a configuration command value from a device external to avehicle (e.g., via a policy update provided by the external device), thevehicle including a first network interface circuit that interprets thefirst network data set, a translation circuit that determines themessage value from the first network data set and encodes the messagevalue in the second data set, and a second network interface circuitthat transmits the second network data set, and an operation 3612 toconfigure, based at least in part on the configuration command value,the first network interface circuit, the second network interfacecircuit, and/or the translation circuit, e.g., such that operations3602, 3604, 3606, 3608 are performed according to the configurationcommand value.

An example operation 3606 includes encapsulating the message value(e.g., a payload), encapsulating entire messages (e.g., a portion or allof the frames of the message(s)), processing the message value, and/orprocessing a portion or all of the frames of the message(s). Exampleoperations 3606 include one or more of: configuring an encapsulationscheme for message(s), configuring an address description for message(s)(e.g., translating addresses according to a target device to receive thedata on a separate network), and/or configuring a sample rate (e.g.,performing an up-sampling and/or down-sampling operation on the firstnetwork data set).

Referencing FIG. 37, an example procedure 3700 to configure a CND formonitoring a network of a vehicle having a mixed network isschematically depicted. The example procedure 3700 includes an operation3702 to interpret first communication data of a first network onboard avehicle, an operation 3704 to interpret second communication data of asecond network onboard a vehicle, the second network of a different typethan the first network, an operation 3706 to generate network statusdata by monitoring the first and second communication data, and anoperation 3708 to transmit the network status data (e.g., storing thedata, communicating the data to an external device, service tool, cloudserver, etc.). An example procedure 3700 further includes an operation3710 to configure a first port (e.g., a port on a network of thevehicle) to mirror a second port (e.g., another port on the network ofthe vehicle), where the first port provides the first communicationdata, for example to provide the first communication data as availablemessages on the second network, and/or to provide the second port as amonitoring port for the first communication data. An example operation3710 includes interpreting a port assignment value (e.g., from a policy,configuration file, determined according to requested data and providingend points for the requested data, and/or determined according to a portcorresponding to a service tool, monitoring device, or the like) thatidentifies a selected port, where the operation 3704 includesidentifying portions of the second communication data corresponding toan identified device (e.g., an end point, port, flow, etc. to bemonitored) and operation 3708 includes transmitting the identifiedportions of the second communications data via the selected port.

An example operation 3706 further includes modifying the network statusdata. Example operations to modify the network status data includemodifying the network status data in response to a selection commandvalue, and including data in the network status data that corresponds toat least one device, application, vehicle function, flow, service group,network, protocol, and/or system identified by the data selectioncommand value. Example and non-limiting protocols include CAN networkand/or OBD protocols.

Referencing FIG. 38, an example procedure 3800 to mirror ports using aCND for a vehicle having a mixed network is schematically depicted. Theexample procedure 3800 includes an operation 3802 to interpret firstcommunications data of a first network at a number of ports of a CND, anoperation 3804 to interpret second communications data of a secondnetwork (of a different type), an operation 3806 to relay the secondcommunications data to the first network using at least one of thenumber of ports (e.g., from a CEG to a CES), and an operation 3808 tomirror a first one of the ports to a second one of the ports. An exampleprocedure 3800 further includes an operation 3810 to interpret a portselection command value (e.g., the receiving port and/or the sendingport of the mirrored communications data) and an operation 3812 toassign the first and/or second one of the ports in response to the portselection command value. An example operation 3810 includes a portassignment command value that identifies an assigned port, identifies adevice on the second network, and where operation 3806 and/or operation3808 includes transmitting identified portions of the secondcommunications data via the assigned port (e.g., to the second network,and/or to the mirrored port).

Referencing FIG. 39, an example procedure 3900 to configure a CND for avehicle having a mixed network is schematically depicted. The exampleprocedure 3900 includes an operation 3902 to interpret, via a firstinterface circuit of a converged network device (CND), a first networkdata set having a first network format, an operation 3904 to determine,via a translation circuit of the CND, a message value from the firstnetwork data set in response to interpreting the first network data set,an operation 3906 to encode, via the translation circuit, the messagevalue in a second network data set having a second network formatdifferent from the first network format, and an operation 3908 totransmit, via a second interface circuit of the CND, the second networkdata set. An example procedure 3900 further includes an operation 3910to interpret a configuration command value, and an operation 3912 tomodify the CND in response to the configuration command value.

Example operations 3912 include interpreting a configuration commandvalue, and modifying the CND in response to the configuration commandvalue. Example operations to modify the CND include selectivelyconfiguring which of one or more portions of the first interfacecircuit, the translation circuit, and/or the second interface circuitare defined at least in part by the first device and/or the seconddevice (e.g., shifting translation and/or interface responsibilitiesbetween different network interface circuits, and/or between a CEGand/or a CES). An example operation 3912 includes generating theconfiguration command value external to the vehicle (e.g., from anexternal device, and/or through a policy update), and transmitting theconfiguration command value to the vehicle (and/or to the CND).

Referencing FIG. 40, an example procedure 4000 to perform a testoperation, diagnostic operation, and/or vehicle control operation isschematically depicted, including operations to configure a CND toperform the operations. The example procedure 4000 may be performed inaddition to operations for procedure 3900, and/or separately in whole orpart. The example procedure 4000 includes an operation 4002 to generatea test command value external to the vehicle, an operation 4004 totransmit the test command value to the CND, and an operation 4006 toexecute a test procedure involving a device (e.g., one of the first orsecond devices of procedure 3900, and/or a third device on the first orsecond network). The example procedure 4000 may be performed,additionally or alternatively, utilizing a diagnostic command value, anactive assistance command value, and/or a vehicle control value (e.g.,commanding an actuator, vehicle function, or the like). In certainembodiments, procedure 4000 allows for remote configuration of the CND,and/or operation of tests, diagnostics, vehicle control functions, orthe like, without requiring knowledge from the external device about thenetwork topology, end point locations, and/or end point local addressesof devices on the vehicle.

Referencing FIG. 41, an example procedure 4100 to regulate a network ofa vehicle having a mixed network is schematically depicted. The exampleprocedure 4100 includes an operation 4102 to interpret firstcommunications data of a first network of the vehicle, an operation 4104to interpret second communications data of a second network of thevehicle, an operation 4106 to relay the first communications data to thesecond network (and/or vice versa), and an operation 4108 to regulatethe second network. Example operations 4108 include restricting therelaying of the first communications data (e.g., limiting a rate,disabling and/or pausing communications, restricting devices that cansend and/or receive relayed data, etc.). Example operations 4108 areperformed in response to a data quantity per unit of time, per operatingevent (e.g., per trip, during certain operating conditions, etc.), basedon a saturation rate of the first network and/or second network, and/orbased on maximum bandwidth of the first network and/or second network(e.g., keeping to a total bandwidth limit, limiting relayedcommunications to a selected fraction of available bandwidth, etc.).Example operations 4108 include prioritizing portions of the firstcommunications data and/or the second communications data for therelaying, according to any prioritizing operations and/or grouping(e.g., end points, flows, applications, vehicle functions, servicegroups, etc.) set forth throughout the present disclosure. Exampleoperation 4108 include up-sampling, down-sampling, encapsulating, and/orprocessing relayed messages and/or portions thereof (e.g., payloads,selected messages, frame portions, metadata, etc.).

Referencing FIG. 42, an example procedure 4200 to regulate inter-networkcommunications of a vehicle having a mixed network is schematicallydepicted. The example procedure 4200 includes an operation 4202 tointerpret first communications data of a first network onboard avehicle, an operation 4204 to interpret second communications data of asecond network onboard the vehicle, an operation 4206 to relay the firstcommunications data to the second network (and/or vice versa), and anoperation 4208 to regulate the relaying of the first communications dataand/or the second communications data. Operation 4208 includes anyregulating operations described throughout the present disclosure, andmay be performed in response to the first network, second network, arelaying device (e.g., a CEG, a CES, and/or a network interfacecircuit), a memory storage (e.g., a buffering memory and/or a short termmemory storage for network communications), including characteristics ofthese, operating conditions of these and/or the vehicle, and/oroff-nominal conditions present for any of these and/or for the vehicle.

Referencing FIG. 43, an example procedure 4300 to support CAN statusdetermination using ethernet based monitoring is schematically depicted.The example procedure 4300 includes an operation 4302 to interpret anethernet based data set via one or more physical ports of a firstinterface circuit of an ethernet switch (e.g., forming a CES) disposedon a vehicle, an operation 4304 to determine a message value from theethernet data set using a translation circuit (e.g., on the ethernetswitch and/or on a CAN gateway and/or CEG), an operation 4306 to encodemessage(s) from the ethernet based data set into messages for a CANbased data set. Operations 4304, 4306 are described going from theethernet based data set to the CAN based data set, but operations mayadditionally or alternatively go from the CAN based data set to theethernet based data set. The example procedure 4300 further includes anoperation 4308 to transmit the CAN data set (e.g., thereby sending anethernet message to a CAN based device, and/or sending a CAN message toan ethernet device) using a second interface circuit. An exampleprocedure 4300 further includes an operation 4310 to interpret aconfiguration command value, and an operation 4312 to modify thetranslation circuit in response to the configuration command value(e.g., changing message processing, addressing, encapsulationcharacteristics, up-sampling values, down-sampling values, maximum datarates, etc.). An example operation 4310 includes receiving theconfiguration command value from an external device (e.g., as a request,message, policy update, etc.). An example operation 4312 includesproviding the configuration command value to an ethernet switch, CEG,configurable CAN gateway, or the like. The example procedure 4300 may beutilized to perform testing, active diagnostics, active assistance,and/or vehicle control, where devices across a mixed network areutilized to perform the operations. Example operations may utilize anyend point, vehicle function, application, flow, service group, or thelike of the vehicle. Example operation may utilize a system, and/or acomponent related to a system, such as a prime mover of the vehicle, anengine of the vehicle, a driveline of the vehicle, a transmission of thevehicle, a braking system of the vehicle, a fuel system of the vehicle,and/or an electrical system of the vehicle.

Referencing FIG. 44, an example procedure 4400 to provide ethernetmonitoring on a vehicle having a mixed network is schematicallydepicted. The example procedure 4400 includes an operation 4402 totranslate ethernet communications data into CAN communications data, anoperation 4404 to translate CAN communications data into ethernetcommunications data, and an operation 4406 to generate network statusdata by monitoring the translated CAN and ethernet communications data.The procedure 4400 further includes an operation 4408 to transmit thenetwork status data—for example by storing the data, communicating thedata to an external device, and/or transmitting the data to a servicetool, web application, cloud server, third party application, etc.

An example procedure 4400 further includes an operation 4410 toconfigure a first ethernet port interpreting the first ethernet data,and an operation 4412 to mirror communications of the first ethernetport to a second ethernet port. In certain embodiments, the firstethernet port may be a port whereby CAN communications data (e.g., fromoperation 4404) is provided to the ethernet network. In certainembodiments, operation 4408 to transmit the network status data includesoperation 4412 to mirror the communications of the first ethernet portto the second ethernet port. Additionally or alternatively, theoperation 4406 to generate the network status data is performed on atleast a portion of the data provided at operation 4412, and operation4406 to generate the network status data may be performed on-vehicle,off-vehicle, and/or a combination thereof.

Referencing FIG. 45, an example procedure 4500 to operate a mixednetwork system on a vehicle is schematically depicted. The exampleprocedure 4500 includes an operation 4502 to generate a message valuevia a first vehicle control device on a first network disposed onboard avehicle, an operation 4504 to transmit the message value to a secondvehicle control device on a second network disposed onboard the vehicle,and an operation 4506 to perform a control operation to the vehicle(e.g., moving a sensor and/or actuator, performing a vehicle function,and/or collecting specified data) in response to receiving the messagevalue at the second vehicle control device. Example and non-limitingvehicle control device(s) include any sensor, actuator, and/orcontroller onboard the vehicle. Example and non-limiting vehicle controldevice(s) include a system, and/or a component related to a system, suchas a prime mover of the vehicle, an engine of the vehicle, a drivelineof the vehicle, a transmission of the vehicle, a braking system of thevehicle, a fuel system of the vehicle, and/or an electrical system ofthe vehicle. In certain embodiments, the first vehicle control deviceand/or second vehicle control device may be capable to perform, in wholeor part, one or more operations of the other one of the vehicle controldevices. In certain embodiments, operation 4502 includes generating amessage to command one of the vehicle control devices to take over, inwhole or part, one or more operations of the other one of the vehiclecontrol devices. In certain embodiments, the vehicle control devices arepositioned on networks of different types. In certain embodiments, theprocedure 4500 includes an operation 4508 to provide data, previouslycommunicated to one of the vehicle control devices, to the other one ofthe vehicle control devices. Operation 4508 may be performed in additionto the previous communications (e.g., both vehicle control devicesreceive the data), and/or as a replacement to the previouscommunications (e.g., in response to a failure of the previouscommunications, and/or ceasing the previous communications whenoperations 4508 are commenced). In certain embodiments, operation 4508includes providing alternate data (e.g., data for a different executableoperation of the replacement control device, which is nevertheless asubstitute in whole or part of the original control device), data from adifferent source (e.g., from a different end point than a source of theprevious communications), and/or data processed distinctly (e.g., havinga different resolution, communication rate, units, etc.) from theprevious communications. In certain embodiments, operations 4508,including vehicle controller substitutions and/or communication changes,are performed in response to requests from the control devices (e.g.,separate data requests are sent from the control devices in response tooperational changes) and/or according to a configuration file and/orpolicy.

An example procedure 4500 includes operation 4504 to transmit themessage value over one or more intermediate networks (e.g., from a CANnetwork on the first network zone to a CAN network on a third networkzone, tunneling through an ethernet network on a second network zone).In certain embodiments, the intermediate network may be a distinct typeof network relative to the first network and/or the second network.Example and non-limiting operations 4506 include one or more of:acquiring data from a component of the vehicle; actuating a component ofthe vehicle; and/or controlling another vehicle control device. Exampleoperations 4506 may utilize any end point, vehicle function,application, flow, service group, or the like of the vehicle. Exampleoperations 4506 may utilize a system, and/or a component related to asystem, such as a prime mover of the vehicle, an engine of the vehicle,a driveline of the vehicle, a transmission of the vehicle, a brakingsystem of the vehicle, a fuel system of the vehicle, and/or anelectrical system of the vehicle. Example operations 4506 may utilize asystem, and/or a component related to a system, such as an infotainmentsystem of the vehicle, an environmental system of the vehicle, a safetysystem of the vehicle, and/or a security system of the vehicle.

Referencing FIG. 46, an example procedure to 4600 to operate a mixednetwork system on a vehicle is schematically depicted. The exampleprocedure 4600 includes an operation 4602 to generate a message valuevia a first vehicle control device on a first network of the vehicle, anoperation 4604 to transmit the message value (and/or a processed and/orencapsulated version of the message value) via a second network to anexternal device at least selectively communicatively coupled to thevehicle, and an operation 4606 to interpret the message value via theexternal device. The example procedure 4600 includes an operation 4608to test the first vehicle control device via the external device, and/orto configure the first vehicle control device via the external device(e.g., providing direct commands or requests, updating a policy, and/orupdating a configuration file). An example procedure 4600 includes anoperation 4609 to configure a second vehicle control device on thesecond network via the external device, which may be responsive tooperation 4604, 4606, and/or 4608.

An example operation 4604 includes translating the message value (e.g.,using a CND, CEG, CES, and/or a network interface circuit) from a firstformat (e.g., for the first network) to a second format (e.g., for thesecond network). An example operation 4608 includes configuring the CND(and/or a CEG, CES, and/or a network interface circuit) via the externaldevice. The example procedure 4600 may additionally or alternativelyinclude transmitting one or more message values over an intermediatenetwork interposed between the first and second networks (e.g.,reference FIGS. 4, 23, 45 and the related descriptions).

An example procedure 4600 includes an operation 4610 to generate anexternal message value via the external device, and an operation 4612 totransmit the external message value to the first network. Operation 4612may further include interpreting the external message via a vehiclecontrol device (e.g., which may be the first vehicle control deviceand/or another vehicle control device(s), such as to determine theexternal message content, and thereby perform a control operation, datacollection operation, active diagnostic operation, active assistanceoperation, test operation, updating operation for a configuration fileand/or policy, etc.). Example operations 4612 may utilize any end point,vehicle function, vehicle controller, application, flow, service group,or the like of the vehicle. Example operations 4612 may utilize asystem, and/or a component related to a system, such as a prime mover ofthe vehicle, an engine of the vehicle, a driveline of the vehicle, atransmission of the vehicle, a braking system of the vehicle, a fuelsystem of the vehicle, and/or an electrical system of the vehicle.Example operations 4612 may utilize a system, and/or a component relatedto a system, such as an infotainment system of the vehicle, anenvironmental system of the vehicle, a safety system of the vehicle,and/or a security system of the vehicle.

Referencing FIG. 47, an example system 4700 is provided for providingextra-vehicle communication control, consistent with embodiments of thepresent disclosure. The example system includes a vehicle 102 having afirst network zone 5612 and a second network zone 5614, where the secondnetwork zone 5614 is of a different type than the first network zone5612. The example system 4700 includes a CND 108 interposed between thefirst network zone 5612 and the second network zone 5614. The CND 108interposed between the network zones 5612, 5614, includes physicalinterposition (e.g., communications between the network zones 5612, 5614pass through the CND 108, and/or through a device controlled by the CND108 such as a CEG, CES, or other network interface circuit) and/or alogical interposition (e.g., where communications between the networkzones 5612, 5614 pass through a device controlled by the CND 108, and/orwhere the CND 108 regulates communications between the network zones5612, 5614 such as data values passed, configuration of the data values,data rates, up-sampling and/or down-sampling of data, encapsulationoperations, frame inclusion and/or processing of passed communications,etc.).

The example system 4700 further includes a policy manager circuit 5602that interprets a policy 5606 including an active diagnostic description4705, and a diagnostic execution circuit 4702 that provides a diagnosticcommand value 4712 to an end point of a network zone 5612, 5614 inresponse to the active diagnostic description 4705. The example system4700 includes end points of the first network zone 5612 (end points4708) and end points of the second network zone 5614 (end points 4710).In the example system 4700, an end point 4708, 4710 includes a deviceresponsive to the diagnostic command value 4712. Example andnon-limiting diagnostic command values 4712 include: a command tocollect one or more data values; a command to operate an actuator;and/or a command to operate a vehicle function (e.g., provide an enginespeed, power level, or higher level function such as executing aregeneration mode, scheduled test operation, etc.). The example system4700 allows for the execution of an active diagnostic test, requested byan external device, to be successfully performed regardless of thedistribution of end points 4708, 4710 throughout networks of thevehicle, including where an end point has moved between networks, and/orwhere a given diagnostic command value 4712 is utilized to performactive diagnostic tests across a range of vehicles having varyingnetwork configurations and distribution of end points 4708, 4710.

Referencing FIG. 48, an example end point 4708 includes a device controlcircuit 4802 that interprets the diagnostic command value 4712, andprovides an actuator command value 4804 in response to the diagnosticcommand value 4712. The example end point 4708 includes, or isassociated with, an actuator 4806 responsive to the actuator commandvalue 4804. For example, a diagnostic command value 4712 may include acommand such as “lock the driver door”, “close an exhaust gasrecirculation valve”, “raise a motor temperature to 80° C”, etc.,allowing for an abstraction between the diagnostic command value 4712and actuator 4806 responses to achieve the diagnostic command value4712. Additionally or alternatively, the diagnostic command value 4712may be associated with a complex operation or series of operations, suchas a full test sequence or the like, and accordingly numerous end points4708, 4710 and/or actuators 4806 throughout the system 4700 may beimplicated by a single diagnostic command value 4712.

An example system 4700 further includes the diagnostic execution circuit4702 determining whether a vehicle operating condition 4720 isconsistent with the diagnostic command value 4712 before providing thediagnostic command value 4712 to the end point(s) 4708, 4710. Forexample, the diagnostic command value 4712 may include a diagnostic testthat adjusts torque delivery of a prime mover of the vehicle, andassociated vehicle operating conditions 4720 may include parameters suchas: ensuring the vehicle is out-of-gear; ensuring the vehicle is not ina motive power mode; and/or ensuring the vehicle is in a selected testmode. In certain embodiments, the vehicle operating conditions 4720 fora given diagnostic command value 4712 may be set forth in the activediagnostic description 4705, allowing for active control of vehicleoperating conditions 4720 for test performance (e.g., targettemperatures; diagnosing specific conditions such as vehicle launch,altitude operation, or the like) and/or extra-test considerations (e.g.,operator or service personnel safety, fuel economy or emissions, impactto network communication rates, processing demand, and/or memorystorage, etc.). In certain embodiments, the vehicle operating conditions4720 for the given diagnostic command value 4712 may be enforced byanother flow, application, vehicle function, or the like associated withthe vehicle (e.g., torque commands cannot be adjusted separate fromoperator commands unless specified vehicle conditions 4720 are present,etc.). An example system 4700 includes the policy 5606 including adiagnostic execution condition 4706, where the diagnostic executioncircuit 4702 further determines whether the vehicle operatingcondition(s) 4720 are consistent with the diagnostic command value 4712in response to the diagnostic execution condition(s) 4706.

An example system 4700 includes the diagnostic execution circuit 4702further performing a diagnostic data collection operation in response tothe active diagnostic description 4705, and storing a diagnostic dataset 4714 in response to the diagnostic data collection operation. Forexample, the active diagnostic description 4705 may include a number ofdata parameters to be collected, vehicle state conditions to bemonitored, and/or parameter threshold values to be determined (e.g., atemperature above a threshold value). The stored diagnostic data set4714 may include the collected data, vehicle state conditions determinedbased on the collected data, parameter threshold confirmation valuesdetermined based on the collected data, or combinations of these. Thecollected data may be from end points 4708, 4710 responsive to thediagnostic command values 4712 (e.g., confirmation that actuators haveresponded to commands, diagnostic data or fault codes associated withresponsive actuators, etc.), or from end points 4708, 4710 apart fromthose responsive to commands (e.g., observation of a temperature,pressure, speed value, state confirmation, etc. that is not associateddirectly with the actuating end points 4708, 4710).

An example diagnostic execution circuit 4702 performs a processingoperation on data collected in the diagnostic data collection operation,and stores the diagnostic data set 4714 in response to the processingoperation. For example, the stored diagnostic data set 4714 may includestate information, virtual sensor information, negative information(e.g., only storing data associated with operations where a threshold isnot met), up-sampled and/or down-sampled values for the data collected,and/or any other processing operations set forth throughout the presentdisclosure. Example and non-limiting processing operations for the datacollected, or portions thereof, include: compressing the data collected;summarizing the data collected; operating a virtual sensor utilizing thedata collected; determining a vehicle operating condition parameter inresponse to the data collected; determining the diagnostic data set inresponse to a determined vehicle operating parameter; performing anup-sampling operation on the data collected; and/or performing adown-sampling operation on the data collected.

An example diagnostic execution circuit 4702 further communicates thediagnostic data set 4714 to an external device (e.g., 5618) in responseto the diagnostic data collection operation. The external devicereceiving the diagnostic data set 4714 may be the same or a differentexternal device than an external device supplying the active diagnosticdescription 4705. An example diagnostic execution circuit 4702 furtherprocesses the collected data before communicating to the externaldevice, which may include the initial processing to determine the storeddiagnostic data set 4714, and/or a further processing operation on thestored diagnostic data set 4714 before communicating to the externaldevice. For example, the diagnostic execution circuit 4702 may store thediagnostic data set 4714, and send a portion of the diagnostic data set4714 (e.g., selected parameters, active diagnostic outcomes, etc.) tothe external device. The example diagnostic execution circuit 4702 thenperforms selected operations such as: further processing the diagnosticdata set 4714 before communicating it to the external device (e.g., toreduce external data communications, in response to selected data fortransmission by the external device, etc.); communicates the diagnosticdata set 4714 to the external device (e.g., responsive to availabilityof an external communication such as a WiFi connection, connectedexternal device, or the like; and/or responsive to a request from theexternal device for all of the diagnostic data set 4714); communicatesselected additional portions of the diagnostic data set 4714 (e.g.,requested data by the external device); keeps the diagnostic data set4714 and/or a further processed form of the diagnostic data set 4714stored for a selected time period; and/or deletes the diagnostic dataset 4714 after the diagnostic execution operation (e.g., according to anoutcome of the active diagnostic test, and/or according to a request ofthe external device). It can be seen that operations of system 4700allow for execution of active diagnostic operations by an externaldevice (e.g., a service tool, service application, cloud-basedapplication, fleet service computing device, and/or third partyapplication) that engages end points on a vehicle across a mixednetwork, allowing for diagnostic operations that do not requireknowledge of the location and/or organization of end points on thevehicle, that can support multiple configurations of a vehicle, and/orcan support changing configurations of the vehicle. Additionally oralternatively, operations of system 4700 allow for scheduledtransmission of data, including reduction of data transmitted whileachieving robust active diagnostic capability, and scheduled consumptionof processing, memory, and inter-network communication resources on thevehicle while achieving the robust active diagnostic capability.

An example system 4700 includes a diagnostic verification circuit 4704that determines a diagnostic confirmation value 4716 based on a responseof the actuator to the diagnostic command value 4712 (e.g., confirmingwhether the actuator performed the commanded function, and/or across agroup of actuators whether the vehicle has performed the activediagnostic according to the active diagnostic description 4705). Theexample diagnostic verification circuit 4704 stores the diagnosticconfirmation value 4716 (e.g., as a part of the diagnostic data set4714) and/or communicates the diagnostic confirmation value 4716 to anexternal device. In certain embodiments, the diagnostic verificationcircuit 4704 adjusts storage and/or communication of the diagnostic dataset 4714 in response to the diagnostic confirmation value 4716—forexample ensuring that the diagnostic data set 4714 is related to aperformance of the active diagnostic. In certain embodiments, thediagnostic execution circuit 4702 may store all or a portion of thediagnostic data set 4714 as a rolling buffer of data, saving a selectedportion of the diagnostic data set 4714 in response to the diagnosticverification circuit 4704 providing the diagnostic confirmation value4716 (e.g., where a diagnostic has a timed value or actuator position asa part of the diagnostic execution, allowing the diagnostic to bedetermined complete when the timer or other accumulating condition iscompleted).

An example active diagnostic description 4705 includes a target devicedescription 4718 (e.g., a fueling actuator, engine controller, dooractuator, mirror position adjustment actuator, etc.) that does notidentify which network zone 5612, 5614 that an end point correspondingto the target device description 4718 is positioned on. The examplesystem includes a configuration circuit 5604 that determines a networkaddress value 4722 for the end point in response to the target devicedescription 4718 (e.g., a port number of an ethernet network, a messageID for a CAN network, etc.), and the diagnostic execution circuit 4702provides the diagnostic command value 4712 to the end point further inresponse to the network address value 4722. For example, the targetdevice description 4718 may include a standardized description for theend point (e.g., engine speed, ambient temperature, passenger seatoccupancy sensor, etc.), and the configuration circuit 5604 may access aconfiguration table relating the standardized description to the localnetwork address for the intended component. Additionally oralternatively, the target device description 4718 may have a descriptionthat matches a baseline product (e.g., a 2020 LX version of a givenvehicle), a description that matches an original version of the vehicle(e.g., as the vehicle was configured after manufacture), and/or adescription that matches an earlier version of the vehicle (e.g., as thevehicle was configured as of a certain date). In certain embodiments,the configuration table or other information utilized by theconfiguration circuit 5604 to determine the network address value 4722may be one or more configuration file(s) maintained by a networkinterface circuit, a configuration file maintained by a policy managercircuit, a configuration file maintained by the CND, and/or aconfiguration file maintained as a part of the policy 5606.

An example active diagnostic description 4705 includes a target devicedescription 4718 (e.g., a fueling actuator, engine controller, dooractuator, mirror position adjustment actuator, etc.) that identifies theend point is on one network zone (e.g., the first network zone 5612),and the configuration circuit 5604 determines the end point is onanother network zone (e.g., the second network zone 5614) in response tothe target device description 4718. For example, the configurationcircuit 5604 may determine that the target device description 4718 ispointing to the wrong device, or a non-existent device, and/or mayfurther determine that the external device is utilizing a previous,different, and/or standardized configuration file to provide the targetdevice description 4718, where the configuration circuit 5604 utilizes alocal configuration file to determine the proper network address valueand/or network zone for the end point intended by the target devicedescription 4718. In certain embodiments, the configuration circuit 5604determines the proper network address value and/or network zone for theend point utilizing other information from the target device description4718, such as parameter names, intended functions, or the like.Similarly, the configuration circuit 5604 can correct the target devicedescription 4718 indicating an incorrect address other than the wrongnetwork zone, such as an address on a first network zone, where thecorrect address is another address on the first network zone.

The operations of the configuration circuit 5604 allow forsimplification of active diagnostic definition (e.g., external devicesdo not require system-specific information about end point locations andnetwork distribution); adaptation of diagnostic execution as end pointsand/or local communicating devices of the vehicle are moved and/orupgraded; and/or allow for a layer of abstraction between externaldevices and the configuration of the vehicle. The simplification and/orabstraction of the active diagnostic definition from the vehicle networkconfiguration allow for reduced cost of active diagnostic developmentand roll-out, and increased user base for active diagnostic development(e.g., with enhanced protection of confidential information such asvehicle configuration information and/or data compartmentalization)which can enhance overall diagnostic capability, enhance vehicleoperator experience, and increase competition and implied competitionfor active diagnostic development and implementation.

Referencing FIG. 49, an example system 4900 includes a vehicle 102having a first legacy network zone 4902 and a second high capabilitynetwork zone 4904. For example, the first legacy network zone 4902 maybe a first network type, such as a CAN bus, and the second highcapability network zone 4904 may be a second network type, such as anethernet network. In certain embodiments, the second high capabilitynetwork zone 4904 may be of the same type as the first legacy networkzone 4902, but may be a higher capability version such as a high speedCAN bus, a higher speed ethernet network, or the like. In certainembodiments, a system 4900 such as that depicted in FIG. 49 may bepresent where a vehicle is migrating to an upgraded network type, suchas during a transition over a number of model years of the vehicles, asnew components are added to a vehicle that utilize a higher capabilitynetwork, and the like.

The example system 4900 includes CND 108 interposed between the firstlegacy network zone 4902 and the second high capability network zone4904, where the CND 108 includes a policy manager circuit 5602 thatinterprets a policy 5606 including an external communication value 4906,and an external communication control circuit 4908 that regulatescommunications between an external device 5618 and end points of thefirst legacy network zone 4902 and/or end points of the second highcapability network zone 4904 in response to the external communicationvalue 4906. For example, external communications between end points ofthe first legacy network zone 4902 may be limited to reduce traffic onthe first legacy network zone 4902 that are created by communications toand from the external device 4918, and/or due to a sensitivity of endpoints on the first legacy network zone 4902 (e.g., where vehiclecontrols and/or proprietary information are maintained on the firstlegacy network zone 4902, and/or where security protocols associatedwith the first legacy network zone 4902 are more limited than thoseavailable with the second high capability network zone 4904). In anotherexample, external communications between end points of the second highcapability network zone 4904 may be limited to reduce externaltransmissions (e.g., through a transceiver of the vehicle, utilizing aparticular data provider, etc.) from the vehicle (e.g., where highercapability devices on the second high capability network zone 4904 mayhave the capability to generate high data rates), due to the potentiallylarge number of devices on the second high capability network zone 4904,including devices that may be recently added to the vehicle (andaccordingly do not have a long history of know usage, security vetting,and/or vehicle operations impact data) and/or devices that may be addedby entities that are not as closely controlled as providers of deviceson the first legacy network zone 4902 (e.g., devices that may beprovided by third parties, that relate to recently developed vehiclecapabilities, and/or that are not related to core vehicle functions,such as entertainment providers). The provided reasons for limitingexternal traffic between end points on various networks and externaldevices are non-limiting and provided for illustration, but the externalcommunication control circuit 4908 may regulate communications betweenend points of any network zone and any external device for any reason.

An example system 4900 includes the external communication value 4906including an active diagnostic description—for example diagnosticoperations and/or data collection to be performed as a diagnosticoperation, and which may involve commands to, data collected from,and/or communications with any end point on any network zone of thevehicle. An example system 4900 includes the external communicationvalue 4906 including an active test description—for example a testoperation (e.g., a test of any end point, actuator, sensor, flow,application, vehicle function, and/or vehicle controller on thevehicle), and which may involve commands to, data collected from, and/orcommunications with any end point on any network zone of the vehicle. Anexample system 4900 includes the external communication value 4906including a data request value (e.g., collection of a data parameterfrom any end point, and/or including processing of the data parameter)and/or a vehicle command value (e.g., command of any actuator, display,controller, etc. with any end point). Example and non-limiting externaldevice(s) 5618 include a service tool, a manufacturer tool, a dealertool, and/or a cloud based tool.

An example external communication value 4906 includes a target devicedescription including an identification of a target end point (e.g., anetwork zone, local address, sensor name, actuator name, data parametername, etc.), where the external communication control circuit 4908determines that the end point has a different configuration (e.g., adifferent network zone, local address, sensor name, actuator name, dataparameter name, etc.) than the identification provided in the targetdevice description. In certain embodiments, the external communicationcontrol circuit 4908 may include or utilize a configuration circuit 5604(e.g., reference FIGS. 56, 47 and the related descriptions) to determinethe proper identification for the target end point. An example externalcommunication value 4906 does not include an identification of a targetend point, and the external communication control circuit 4908 providesa proper identification for the target end point based on the externalcommunication value 4906 (again referencing FIGS. 56, 47, and therelated descriptions, including operations of the configuration circuit5604). It can be seen that the operations of system 4900 allow forexternal devices 5618 to operate across a number of vehicleconfigurations, without specific knowledge of end point locations,parameter names, local addresses, or the like, to implement activediagnostics, testing, and data collection. The vehicle configurationsmay represent changes of a vehicle after servicing, replacement ofcomponents (e.g., end points), upgrading of components and/or executableinstructions stored on a computer readable medium, changes over thecourse of model years, and/or changes to a vehicle due to campaigns,upgrades, and/or remanufacturing.

Referencing FIG. 50, an example procedure 5000 to command an actuator inresponse to a diagnostic command value is schematically depicted. Theexample procedure 5000 includes an operation 5002 to interpret a policyincluding an active diagnostic description, an operation 5004 to providea diagnostic command value to an end point in response to the activediagnostic condition, and an operation 5006 to command an actuator inresponse to the diagnostic command value.

Referencing FIG. 51, an example procedure 5100 to command an actuator inresponse to a diagnostic command value is schematically depicted. Theexample procedure 5100 includes an operation 5102 to interpret a policyincluding an active diagnostic description and a diagnostic executioncondition, and an operation 5104 to determine whether a vehicleoperating condition is consistent with the diagnostic executioncondition and/or a diagnostic command value (e.g., determined from theactive diagnostic description). In response to the operation 5104determining YES, the procedure 5100 includes an operation 5004 toprovide a diagnostic command value to an end point in response to theactive diagnostic condition, and an operation 5006 to command anactuator in response to the diagnostic command value.

Referencing FIG. 52, an example procedure 5200 to command an actuator inresponse to a diagnostic command value is schematically depicted. Theexample procedure 5200 includes an operation 5002 to interpret a policyincluding an active diagnostic description, and an operation 5202 toperform a diagnostic data collection operation in response to the activediagnostic description. The example procedure 5200 further includes anoperation 5004 to provide a diagnostic command value to an end point inresponse to the active diagnostic condition, and an operation 5006 tocommand an actuator in response to the diagnostic command value.

Referencing FIG. 53, an example procedure 5202 to perform a diagnosticdata collection operation is schematically depicted. The exampleprocedure 5202 includes an operation 5302 to process collected data(e.g., processing a payload and/or frame information of messages of thecollected data), an operation 5304 to store the collected, processeddata, and an operation 5306 to communicate at least a portion of thestored data to an external device.

Referencing FIG. 54, an example procedure 5400 to store and/orcommunicate a diagnostic confirmation value is schematically depicted.The example procedure 5400 includes an operation 5002 to interpret apolicy including an active diagnostic description, an operation 5004 toprovide a diagnostic command value to an end point in response to theactive diagnostic condition, and an operation 5006 to command anactuator in response to the diagnostic command value. The exampleprocedure 5400 further includes an operation 5402 to determine adiagnostic confirmation value, and an operation 5404 to store and/orcommunicate the diagnostic confirmation value to one or more externaldevices.

Referencing FIG. 55, an example procedure 5500 to command an actuator inresponse to a diagnostic command value is schematically depicted. Inaddition to operations recited in relation to FIG. 50 preceding, theexample procedure 5500 includes an operation 5502 to determine whether atarget device description points to a network address value for thetarget end point(s) related to a commanded actuator (e.g., if the targetdevice description does not point to a network address value, or pointsto an incorrect network address value, then operation 5502 determinesNO). In response to operation 5502 determining YES, the procedure 5500proceeds to operation 5004. In response to operation 5502 determiningYES, the procedure 5500 includes an operation 5504 to supply or adjust anetwork address value for the target end point(s), and then to operation5004.

Referencing FIG. 56, an example system 5600 is provided for providingextra-vehicle communication control, consistent with embodiments of thepresent disclosure. Systems described throughout the present disclosuremay be provided on a mobile application such as a vehicle or asdescribed throughout the present disclosure. Example systems hereinrecite particular arrangements, for example of a converged networkdevice (CND) 108, circuits, controllers, or other components. Thearrangements are provided for clarity of the present description, butcomponents may be distributed, combined, divided, and/or have distinctrelationships to those depicted to form systems and to performprocedures described herein.

Circuits, controllers, processors, or other devices set forth herein areconfigured to functionally perform operations as described herein, andmay include computing components such as processors, memory, and/orcommunications components. Additionally or alternatively, such devicesmay include logic circuits, hardware configured to perform one or morefunctions of the device, sensors, actuators, and/or display devices ofany type. A given circuit, controller, processor, or other such devicemay be distributed and/or grouped, in whole or part, with other suchdevices.

Certain operations herein are described as interpreting or receivingparameters, or obtaining parameter values using other similar languagedepending upon the context. Any such operations include receiving theparameter value as a network communication; receiving the parametervalue from a sensor; receiving the parameter value as a feedback value(e.g., an actuator position, a reported fault code value, etc.);retrieving the parameter value from a memory location accessible to theinterpreting or receiving device; receiving the parameter value as acommand; receiving the parameter value as a response to a request fromthe receiving or interpreting device; and/or receiving pre-cursor valuesfrom which the parameter is, at least in part, determined (e.g.,operating a virtual sensor using other information to determine theinterpreted or received parameter value; determining a state value basedupon the received information, where the state value is the received orinterpreted value for the purpose of the description; and/or usingreceived information to infer the interpreted value). Any suchoperations may further include more than of these (e.g., interpreting aparameter value in distinct ways at different times, operatingconditions, during off-nominal conditions, depending upon a source ofthe parameter value, and/or depending upon the usage or purpose of theinterpreted parameter value at a given time or during certain operatingconditions), and/or combinations of these (e.g., operating a virtualsensor on received information to determine a pre-cursor value, anddetermining the interpreted parameter value in response to thepre-cursor value).

The example system 5600 includes a vehicle 102 having a first networkzone 5612 and a second network zone 5614, where the first network zone5612 and the second network zone 5614 are different types of networks.Without limitation to any other aspect of the present disclosure,different types of networks as described herein contemplates anydifference in the networks, such as: a difference in a networkcapability (e.g., band width, message size, latency, noise sensitivity,etc.); a difference in a network protocol at any layer (e.g., hardwaretype; message frame requirements; addressing schemes; acknowledgmenttypes, requirements, or capabilities; casting availability such asunicast, multi-cast, and/or broadcast); a network standard type (e.g.,Controller Area Network (CAN); Media Oriented Systems Transport (MOST)network; Local Interconnect Network (LIN); FlexRay network;Time-Triggered Protocol (TTP) network; Low-Voltage DifferentialSignaling (LVDS) network; Audio Video Bridging (AVB) compliant network;a customized version of any one or more of the foregoing; and/or aproprietary version of any one or more of the foregoing). An examplenetwork zone includes an electrical signal zone (e.g., a network where acorresponding network interface circuit interprets an electrical signalvalue as a communication, and/or provides an electrical signal value asa communication to an end point of the electrical signal zone, such as asensor providing certain electrical values indicating a sensed parametervalue, a diagnostic value, or the like, and/or an actuator responsive tocertain electrical values to move to a selected position and/or apply aselected force, and/or where the actuator may additionally oralternatively provide feedback information and/or diagnostic informationon the electrical signal zone). Electrical signals for an electricalsignal zone may be of any type, including at least: voltage values;frequency values; current values; and/or configured pulse-widthmodulated (PWM) values such as duty cycles, amplitudes, selectedperiods, and the like.

The example system 5600 further includes a policy manager circuit 5602that interprets a policy 5606 including a network regulation description(not shown), and a configuration circuit 5604 that configures at leastone network interface circuit (e.g., a first network interface circuit5608 corresponding to the first network zone 5612 and/or a secondnetwork interface circuit 5610 corresponding to the second network zone5610) in response to the policy 5606. For example, the policy 5606 maybe provided by an external device 5618, and/or may be previously stored(e.g., at a time of manufacture, assembly, and/or during a previousupdate from the external device 5618), where the policy 5606 includesthe network regulation description having selected indications ofdevices on the vehicle 102 for capability to utilize the network zones5612, 5614, to communicate between zones, and/or to communicate withexternal devices 5618.

An example system 5600 includes the first network interface circuit 5608provided as a part of a CEG, where the first network zone 5612 is a CANbus network, and the second network interface circuit 5610 provided as apart of a CES, where the second network zone 5610 is provided as anethernet network. In the example, the first network interface circuit5608 provides selected communications from the first network zone 5612to the second network interface circuit 5610 at a selected port of theethernet network, and/or receives selected communications from thesecond network zone 5614 at the selected port of the ethernet network,thereby providing for inter-network communications between the firstnetwork zone 5612 and the second network zone 5614. In the example,communications from the first network zone 5612 to an external device5618 may be provided through the second network zone 5614 (e.g., wherethe external device 5618 is coupled to the second network zone 5614and/or connected wirelessly to the vehicle 102), or directly to theexternal device 5618 (e.g., where the external device 5618 is coupleddirectly to the first network zone 5612 or CAN bus).

An example system 5600 includes the first network zone 5612 as a virtuallocal area network (VLAN), logically separated from the second networkzone 5614, but positioned on at least partially shared hardware with thesecond network zone 5614. In the example, the first network interfacecircuit 5608 and second network interface circuit 5610 may be operatedas elements of a network switch or router, controlling communicationbetween end points of the first network zone 5612 and second networkzone 5614 in response to the policy 5606.

Devices on the vehicle 102 that are regulated by the policy include,without limitation, one or more of: an end point of a network zone; aflow associated with a communicating device (e.g., an end point or anapplication); an application associated with a communicating device(e.g., an end point). For example, an end point of the first networkzone 5612 (e.g., a backup camera on the vehicle 102) may request orperform communications on a network of the vehicle, but may beassociated with more than one application or flow (e.g., associated witha first flow relating to vehicle reverse movement operations at a firstoperating condition, and associated with a second flow relating tovehicle security operations at a second operating condition), andaccordingly the communications of the backup camera on the vehicle 102may have different regulation parameters depending upon the flowassociated with the operations at the moment. In certain embodiments, anend point is associated with more than one application or flow, and theend point is regulated according to a highest priority one of theassociated applications or flows (e.g., to reduce communicationrequirements, such as determining the application or flow that isrequesting the immediate communication to be regulated, and/or to reduceprocessing time to determine which application or flow is requesting theimmediate communication). In certain embodiments, an end point isassociated with more than one application or flow, and the end point isregulated according to priority of the application or flow requestingthe immediate communication.

Devices on the vehicle 102 that are regulated by the policy may bereferenced herein, without limitation, as a local communicating device.Local communicating devices include, without limitation: an end point ofa network zone; an application; a flow; a vehicle function (e.g., powermanagement, cabin comfort, traction control, etc.); a sensor device; aservice group; and/or a vehicle controller (e.g., an engine controller,a transmission controller, an anti-lock brake system (ABS) controller,an advanced driver assistance system (ADAS) controller, etc.). It can beseen that a given component, such as an end point of a network zone, maybe a first local communicating device during one operating condition,and a second local communicating device during another operatingcondition—for example depending upon the vehicle operating condition(e.g., shutdown, motive operation, parked operation, etc.), and/or maybe a first local communicating device for a first purpose (e.g., a brakecontroller performing active traction control operations) and a secondlocal communicating device for a second purpose (e.g., the brakecontroller providing data to be stored for diagnostic operations).Additionally, it can be seen that the distribution of communicationdevices between applications, flows, controller, vehicle functions, andthe like, depends upon the organizing strategy of the particular system,design choices made by a manufacturer or other entity having designand/or configuration control of the system, and the like. For example,traction control may be provided by a unified vehicle controller for agiven system (e.g., which may treat the traction control as a vehiclecontroller for network regulation purposes); provided by distributedcontrollers for another system (e.g., which may treat the tractioncontrol as a vehicle function for network regulation purposes); and/ormay be treated as a logically grouped set of operations for anothersystem (e.g., which may have any hardware organization including thepreviously described organizations, and which may treat the tractioncontrol as an application or flow for network regulation purposes). Oneof skill in the art, having the benefit of the present disclosure andinformation ordinarily available when contemplating a particular system,can readily determine the organizational scheme and network regulationfor local communicating devices of the system. The organizational schemefor local communicating devices includes the inclusion and/orassociation of end points of the network zones, and/or certaincommunications (including source or destination communications for theend point(s)) with one or more of: particular end points, vehiclecontrollers, vehicle functions, applications, and/or flows of thesystem.

Certain considerations to determine the organizational scheme include,without limitation: the number, types, capabilities, andinter-connection bandwidth of network zones of the system; the availablesize and/or granularity for policy(ies) of the system; the availableprocessing power available for implementation of the policy(ies) of thesystem; the number and distribution of vehicle controllers and othercontrollers throughout the system; the expected change of the systemover time (e.g., availability to reconfigure, remanufacture, and/orre-spec the vehicle; expected changes in coming model years associatedwith the vehicle; and/or the level of consumer and/or third-partycustomization of the vehicle that is available or expected); the numberand distribution of sensors and/or actuators throughout the system, andthe connectivity of the sensors and/or actuators to a network zone(e.g., consolidation at controllers, and/or consolidation using smartsensors/actuators capable to directly interface with a network zone);the presence, number, and distribution of multi-purpose communicatingelements on the system (e.g., sensors, actuators, controllers, and/ordata values that service multiple vehicle functions, flows, and/orapplications); the presence, number, and distribution of multi-purposedata elements on the system (e.g., sensors, actuators, controllers,and/or data values that provide redundant capability to support a givenvehicle function, flow, and/or application); and/or the expectedutilization of a network aspect (e.g., communications on a network zone,external communication data rate and/or aggregate data communicated,inter-network communications, etc.) relative to a related capacity(e.g., a bandwidth of a network zone, external communication bandwidth,external communication data limit, inter-network communications, etc.).

An example policy manager circuit 5602 receives a policy communication5620 from an external device 5618, and interprets the policy 5606 byperforming an operation such as storing the policy 5606 (e.g., in amemory location accessible to the policy manager circuit 5602, and/ordistributed throughout a number of memory locations) and/or updating astored policy 5606. In certain embodiments, the policy manager circuit5602 configures the policy 5606 for utilization by network regulatingaspects of the system 5600, for example by updating a number ofconfiguration files utilized by interface circuits 5608, 5610, adjustinghigh level descriptions of the policy communication 5616 (e.g., limitexternal communication data to 32 GB per month) to executable commandsby network regulating aspects of the system 5600, adjusting referencevalues of the policy communication 5620 (e.g., associating a localaddress value of an end point referenced in the policy communication5616, such as when an end point has moved without notification to theexternal device 5618, and/or where specific addressing information oflocal devices is abstracted from the external device 5618, etc.),associating system-specific nomenclature to elements of the policydescription 5620 (e.g., local parameter value names or IDs, flow namesor IDs, application names or IDs, etc.), or the like.

An example system 5600 includes the external device 5618 communicativelycoupled to the policy manager circuit 5602 through at least one of thefirst network zone 5612 or the second network zone 5614—for exampleusing a CAN bus port, OBD port, ethernet port, proprietary port, orother direct coupling to a network zone. An example system 5600 includesthe external device 5618 communicatively coupled to the policy managercircuit 5602 through a wireless connection, such as a WiFi connection,cellular connection, and/or Bluetooth connection.

An example system 5600 includes the policy manager circuit 5602verifying the policy 5606, as communicated by the policy communication5616, before performing the storing and/or updating of the policy 5606.For example, the policy manager circuit 5602 may require anauthentication of the external device 5618, and/or a determination ofthe permissions associated with the external device 5618, beforeperforming a change to the policy 5606. In certain embodiments, thepolicy manager circuit 5602 may determine permissions associated withthe external device 5618, an entity utilizing the external device 5618,an application or flow utilizing the external device 5618, or the like,before performing a change to the policy 5606. In certain embodiments,the policy manager circuit 5602 may reject the policy communication 5616if the policy 5606 implied by the policy communication 5616 exceeds anauthority associated with the external device 5618, and/or if the policy5606 cannot be implemented (e.g., executing the policy 5606 would exceedthe capability of the system 5600, such as a bandwidth of a networkzone, an external communications limit, a memory storage limit, or thelike). In certain embodiments, the policy manager circuit 5602 maypartially implement the policy communication 5616 if the policy 5606implied by the policy communication exceeds an authority associated withthe external device 5618, and/or if the policy 5606 cannot be fullyimplemented. For example, the policy manager circuit 5602 may implementthe authorized portions of the policy communication 5616, and/orimplement portions of the policy communication 5616 than the system 5600has capability to implement. In certain embodiments, the policy managercircuit 5602 implements portions of the policy communication 5616, forexample where a system capability would be exceeded by a fullimplementation, according to: a priority of associated end points,flows, applications, vehicle functions, etc. of the policy communication5616 (e.g., implementing higher priority aspects until a limit isreached); and/or maximizing an implementation value of the policycommunication 5616 (e.g., associating a value for each aspect accordingto an associated priority, importance, benefit description, etc. of thegiven aspects; for example where meeting a group of slightly lowerpriority aspects of the policy would exceed the value of meeting only asingle higher priority aspect of the policy).

An example policy manager circuit 5602 provides a policy notification5620 to the external device 5618 in response to verifying the policy5606. An example policy notification 5620 includes a confirmation thatthe policy 5606 is updated and/or stored according to the policycommunication 5616. An example policy notification 5620 includes anotification that the policy 5606 has not been implemented (e.g., wherethe external device 5618 does not have authorization to implement thepolicy communication 5616). An example policy notification 5620 includesa reason for the rejection of the policy communication 5616 (e.g., alack of authorization, lack of capability, etc.). An example policynotification 5620 includes one or more aspects of a partialimplementation of the policy communication 5616, for example adescription of which aspects of the policy communication 5616 have beenimplemented or rejected, and/or a reason for the partial implementation.In certain embodiments, the policy manager circuit 5602 may provide thepolicy notification 5620 to a separate external device (not shown),either instead of the policy notification 5620 to the first externaldevice 5618, and/or in addition to the policy notification 5620 to thefirst external device 5618. In certain embodiments, the policynotification 5620 to separate external devices may have the sameinformation, or separate information. For example, the policy managercircuit 5602 may provide a simple policy notification 5620 to therequesting external device 5618 (e.g., a rejection of the policycommunication 5616), and a more detailed policy notification 5620 to aseparate external device (e.g., indicating authorizations that preventthe implementation of the policy communication 5616, capacities thatprevent the implementation of the policy communication 5616, and/ordetails related to a partial implementation of the policy communication5616). In certain embodiments, the policy manager circuit 5602 mayprovide a more detailed policy communication 5620 to the requestingexternal device 5618, and a simpler policy communication 5620 to theseparate external device(s).

In certain embodiments, the policy notification 5620 may includeproviding a prompt to a user interface of an external device (notshown), for example allowing an authorized external device, user,entity, or the like, to provide a permission to allow a policy 5606update in response to the policy communication 5616. In a furtherexample, the prompt to the user interface of the external device mayinclude a prompt to one or more of a vehicle owner, a vehicle operator,a vehicle manufacturer, an administrator related to the vehicle (e.g., anetwork administrator, fleet owner, fleet service operator, compliancepersonnel associated with the vehicle, etc.).

Without limitation to any other aspect of the present disclosure,example aspects of a policy 5606 include: a data collection parameter(e.g., data available to at least one network zone of the vehicle, suchas data from any sensor, actuator, controller, and/or end point at leastselectively couplable to a network zone and/or in communication with anend point of a network zone); a data collection permission value (e.g.,a sampling or communication rate; a permission to provide the data valueto a network zone; a permission to request the data value from a networkzone; a resolution value associated with the data; a time lag permissionassociated with the data; a storage permission associated with the datasuch as an amount of data storage authorized, data expiration criteria,and aged data treatment parameters such as compression and/orsummarization operations to be performed on aging data and/or to beperformed if permitted storage becomes limited due to inability tocommunicate the stored data externally or competing storage prioritiesintervene with the planned available storage); a service publicationpermission value (e.g., an authorization to publish the availability ofa service, which may include scheduled authorization to publish to somelocal communicating devices, external applications, and the like, butnot to others; and/or an authorization to publish details of theavailable service such as data parameters provided, actuators available,etc.); a service subscription permission value (e.g., published servicesthat are visible to the associated local communicating device; servicedetails that are available to the associated local communicating device;and/or permissions to subscribe to services for the associated localcommunicating device); and/or an external communication permission value(e.g., data rates, associated parameters, external addresses allowed,APNs allowed, aggregate data communication permissions, etc.). Thepolicy 5606 includes any one or more of the foregoing associated withlocal communicating devices (e.g., end points, controllers, vehiclefunctions, flows, applications, sensor devices, etc.), external devices(e.g., specific devices or device categories, entities, and/orapplications). In certain embodiments, a given flow, application, orvehicle function may include aspects associated with a localcommunicating device, and other aspects associated with an externaldevice (e.g., a route predictor application that utilizes localcommunicating devices combined with an external application such as acloud based application or a web based application).

Referencing FIG. 57, an example procedure 5700 to regulatecommunications between networks of a different type on a vehicle isschematically depicted. The example procedure 5700 includes an operation5702 to interpret a policy including a network regulation description,and an operation 5704 to regulate communications between end points of afirst network and end points of a second network in response to thenetwork regulation description.

Referencing FIG. 58, an example procedure 5800 to regulatecommunications between networks of a different type on a vehicle isschematically depicted. The example procedure 5800 includes an operation5702 to interpret a policy including a network regulation description,and an operation 5802 to receive a policy communication from an externaldevice. The procedure 5800 includes an operation 5804 to determinewhether the policy is verified—for example if the external device isauthorized to update the policy, if the system is capable to performaccording to the policy, if the policy violates any security criteria,if the performance of the policy would exceed a data storage limit or acommunication limit, etc. In response to operation 5804 indicating YES,the procedure 5800 includes an operation 5806 to store and/or update thepolicy, and the operation 5704 to regulate communications between endpoints of a first network and end points of a second network in responseto the network regulation description. In response to operation 5804indicating NO, the procedure 5800 optionally includes an operation 5808to provide a notification to the external device (and/or to otherexternal devices), and the operation 5704 to regulate communicationsbetween end points of a first network and end points of a second networkin response to the network regulation description (e.g., utilizing theprevious policy, a default policy, or the like).

Referencing FIG. 59, an example procedure 5900 to regulatecommunications between networks of a different type on a vehicle isschematically depicted. The example procedure 5900 includes an operation5702 to interpret a policy including a network regulation description,and an operation 5802 to receive a policy communication from an externaldevice. The procedure 5900 includes an operation 5804 to determinewhether the policy is verified—for example if the external device isauthorized to update the policy, if the system is capable to performaccording to the policy, if the policy violates any security criteria,if the performance of the policy would exceed a data storage limit or acommunication limit, etc. In response to operation 5804 indicating YES,the procedure 5900 includes an operation 5902 to update localconfiguration files of one or more of: a network interface circuit, aCEG, a CES, and/or gateway interface circuit. In response to operation5804 indicating NO, the procedure 5900 optionally includes an operation5808 to provide a notification to the external device (and/or to otherexternal devices). The procedure 5900 includes an operation 5904 toregulate intra-network, inter-network, and/or external communications,using the network interface circuit(s), CEG(s), CES(s), and/or gatewayinterface circuit(s) (e.g., whether updated or not).

The procedures 5700, 5800, 5900 are described in reference to regulatingcommunications between networks on a vehicle, but may additionally oralternatively be adapted to regulate communications between one or morenetworks on a vehicle and extra-vehicle communications (e.g.,communications between a network and an external communication portaland/or an external device).

Referencing FIG. 60, an example system 6000 is depicted for regulatingnetwork communications on a vehicle using a CND that is externallyconfigured. The example system 6000 includes a vehicle 102 having afirst network zone 6002 and a second network zone 6004, for examplenetwork zones of a different type, such as in a vehicle having a mixednetwork. The example system 6000 includes a CND 108 interposed(physically and/or logically) between the network zones 6002, 6004, andhaving a policy manager circuit 6006 that interprets a policy 6014,where the policy 6014 is communicated to the CND 108 from an externaldevice 6003 (e.g., with the external device 6003 providing a policycommunication 6020, where the CND 108 determines the policy 6014 inresponse to the policy communication 6020). The example system 6000includes a configuration circuit 6008 that configures network interfacecircuit(s) (e.g., a first network interface circuit 6010 and a secondnetwork interface circuit 6012) in response to the policy 6014. Thesystem 6000 includes the network interface circuit(s) 6010, 6012regulating communications between end points of the first network zone6002 and the second network zone 6004, for example as configured by theconfiguration circuit 6008. Regulating operations may be performed oninter-network communications (e.g., between network zones),intra-network communications (e.g., between devices on a given networkzone), or other communications (e.g., communications to externaldevices, service tools, user devices, etc.). Any regulating operationdescribed throughout the present disclosure are contemplated for system6000. The example of FIG. 60 includes the policy communication 6020having aspects such as inter-network regulation 6022 parameters,intra-network regulation 6024 parameters, permissions and/orauthorizations 6026 related to the policy, and/or data collectionparameters 6028 related to the policy. The example aspects of the policycommunication 6020, and the corresponding implementation of theseaspects in the policy 6014 on-vehicle, are non-limiting examplesprovided for illustration. A given embodiment may include additionalaspects of the policy, and/or may omit one or more of the depictedaspects.

An example system 6000 includes the external device 6003 being a cloudapplication (e.g., operating on a cloud server or other computingdevice, at least intermittently in communication with the vehicle), aweb based tool, combinations of these, and/or having portions of theexternal device 6003 being one of these, with other portions providedthrough other implementations (e.g., a service tool, fleet tool,operator mobile device, etc.).

An example external device 6003 includes a policy development interface6015 that accepts policy input value(s) 6032 from a number of users(e.g., via user input device(s) 6030), a policy formulation engine 6016that compiles the policy input value(s) 6032 into a policy 6014 (and/orinto one or more aspects of a policy communication 6020 utilized toprovide the policy to the CND 108), and a policy application engine 6018that communicates the policy 6014 (and/or the policy communication 6020)to the CND 108. An example policy development interface 6015 interactswith user devices 6030 to accept policy input value(s) 6032, for exampleoperating a GUI with the user devices 6030, operating an interactingapplication such as a web based tool, cloud application, mobileapplication, etc. to receive the policy input value(s) 6032. In certainembodiments, the policy development interface 6015 accepts aconfiguration file (e.g., an XML file, standardized format file, etc.)from a user device 6030 as a policy input value 6032. In certainembodiments, accepting the policy input value(s) 6032 includesoperations such as: determining whether a policy input value 6030 isproper (e.g., formatting, permissions associated with the user deviceand/or entity associated with the user device, compatibility of thepolicy input with available parameters, functions, sampling rates, etc.on the vehicle, and the like); parsing the policy input value 6032 intoportions (e.g., data collection, network usage permission, externalvehicle communication permissions, associations such as flows,applications, vehicle functions, service groups, and the like for policyportions, etc.); associating metadata with the policy input value 6032or portions thereof (e.g., time stamps; versions of a policy, relatedapplications, etc.; identifiers associated therewith, such as a user,user role, related entity, user device identifier, etc.); and/orprioritizing between policy input values 6032 (e.g., such as when policyinput values 6032 are not compatible, and/or cannot all be included suchas when an aggregate policy size limitation would be exceeded, and whichmay be according to any aspect of the policy input value such as datatype or related vehicle function, and/or according to any associationwith the policy input value 6032 such as an associated entity, etc.).

An example system 6000 includes a policy interaction engine 6019 thatgenerates policy interaction code 6034, such as header file(s),parameter definition(s), and/or an API declaration. The policyinteraction engine 6019 facilitates a user-friendly development of apolicy and/or portions of a policy by users, applications, and/or tools,allowing users to conveniently interact with aspects of the policy thatthey are authorized to develop, to select available parameters,functions, control commands, and the like, and to minimizevehicle-specific knowledge requirements for users developing the policyand/or aspects of the policy.

An example system 6000 includes a policy 6014 having a data collectiondefinition (e.g., data parameters to be collected, and/or includinginformation such as processing to be performed, data formats forindividual data elements, data formats for storage of the data such as afile type for the stored data, communication parameters such as datarates, timeliness, treatment of aging data and/or expiration of data,etc., including any data collection parameters set forth throughout thepresent disclosure). An example data collection definition includes atleast one local communicating device (e.g., an end point, flow,application, network zone, vehicle function, service group, etc. asdescribed throughout the present disclosure) corresponding to at leastone data collection parameter. An example system 6000 further includes auser entering an identifier, address, and/or port for a source and/orfor a destination of the collected data (e.g., identifying the localcommunicating device(s) that is(are) the source for the collected data,and/or identifying a destination for the collected data)—e.g., by theuser providing the data collection definition as a policy input value6032 that is thereby implemented as a part of the policy 6014. Anexample system 6000 includes the CND 108 performing a data collectionoperation utilizing the data collection definition, thereby collectingdata from the vehicle according to the user entered parameters for thegenerated data source and/or destination.

An example system 6000 includes an operation to provide all or a portionof the data collection definition, which may be performed instead ofutilizing user-defined portions (e.g., where addresses or otherinformation are intentionally hidden from the user for security purposesand/or to facilitate ease of implementation of user entry of policyinput values), and/or in addition to utilizing user-defined portions(e.g., to correct a user-defined portion that may have an incorrectvalue, to translate a user-defined portion that may be utilizing alegacy addressing value for an end point, etc.). In certain embodiments,the CND 108 may perform operations to provide all or a portion of thedata collection definition, for example utilizing translatinginformation provided in the policy 6014 available to the CND 108, totranslate addresses where an end point of the vehicle has moved (e.g.,between network zones and/or to a different address), or the like. Incertain embodiments, the policy formulation engine 6016 may performoperations to provide all or a portion of the data collectiondefinition, for example to mask addresses from a user device, to allowreference to data parameters according to an industry standard,simplified description, or the like, and/or where certainresponsibilities to perform operations for providing, updating, and/orcorrecting the data collection definition are divided between the CND108 and the policy formulation engine 6016. For example, the CND 108 mayperform certain operations to provide, update, and/or correct the datacollection definition (e.g., local, vehicle-specific operations such aslocal address translations), and the policy formulation engine 6016 mayperform other operations to provide, update, and/or correct the datacollection definition (e.g., server-side operations such as datadestination locations off-vehicle, providing scheduled informationavailability and/or capability to different users, user devices,applications, entities, and the like, etc.).

Referencing FIG. 69, an example visualization management controller 6912is depicted, which is configured to functionally execute operations todepict data flows on the vehicle, and/or to provide visualizations ofthe vehicle network and aspects of the network utilization, CND, endpoints, or the like. The example visualization management controller6912 may be utilized with any system throughout the present disclosure,and/or to perform one or more aspects of operations throughout thepresent disclosure. The visualization management controller 6912 may bedistributed across one or more vehicle controllers, the CND, and/or anexternal device, and/or may be provided on a single one of these. Theaspects of the visualization management controller 6912 that areprovided on-vehicle and/or external to the vehicle may vary dependingupon the characteristics of the system, the entities (e.g., controllers,applications, flows, external devices, third-party applications, etc.)that are expected to access vehicle network data (and/or that will havecapability to access vehicle network data), the communication plan(e.g., the scheme to communicate network data and/or visualization datafrom the vehicle and/or from a cloud storage location), and/or theprocessing plan (e.g., the scheme to process monitoring data intovisualization data, the types of processing to be performed, and thenumber of distinct types of processing to be performed for variousclients of the visualization data). A visualization managementcontroller 6912 may be utilized to monitor vehicle networks (e.g., todiagnose issues on one or more networks, to monitor communications fromlocal communicating devices, and/or to diagnose secondary issues thatmay be presented by unusual network utilization and/or data flow on thevehicle).

The example visualization management controller 6912 includes a vehiclecommunication circuit 6902 that interprets vehicle communications data6908 (e.g., data flow on a network zone, between network zones, throughthe CND or other regulating components, and/or related to particular endpoints, flows, service groups, vehicle controllers, vehicle functions,applications, etc.). Example vehicle communications data 6908 includesone or more of the following: communications between end points of anetwork zone of the vehicle (e.g., on the same or on different networkzones); and/or communications between local communicating device (e.g.,on the same or on different network zones, and/or distributed acrossmore than one network zone). The example visualization managementcontroller 6912 includes a visualization circuit 6904 that generatesvisualization data 6910 (e.g., reference FIGS. 61-68 and the relateddescriptions), and a display interface circuit 6906 that transmits thevisualization data 6910, for example to an external device, to a userdevice (e.g., a service tool, network monitoring tool, a third-partyapplication, and/or an application utilized by a user monitoring thenetwork(s) of the vehicle and/or other aspects of the vehicle related tothe networks and/or data flows of the vehicle). An example visualizationmanagement controller 6912 includes the vehicle communication circuit6902 positioned, in whole or part, on the vehicle (e.g., on the CND, ona vehicle controller, and/or on a network interface circuit), where thevehicle communication data 6908 is provided to a port of a network zone(e.g., a monitoring port, a mirrored port, and/or a port otherwiseaccessible to an external device). An example visualization managementcontroller 6912 includes the visualization circuit positioned on anexternal device, where the display interface circuit 6906 provides thevisualization data 6910 to a user device communicatively coupled to theexternal device. Without limitation to any other aspect of the presentdisclosure, example visualization data 6910 includes one or more of thefollowing: a graphical representation of at least a portion ofcommunications between local communicating devices of the vehicle; agraphical flow representation of at least a portion of communicationspassing through the CND; a graphical flow representation of at least aportion of communications regulated by at least one of the first networkinterface circuit or the second network interface circuit; and/or agraphical flow representation of at least a portion of communicationspassing between the first network zone and the second network zone.Example and non-limiting graphical flow representations include a datatable depicting data flows, and/or any aspects of data flows asdescribed throughout the present disclosure.

Referencing FIG. 61, an example apparatus 6100 is depicted for providingan external network view for one or more networks of a vehicle having amixed network. The example apparatus 6100 may be utilized in conjunctionwith any vehicle described throughout the present disclosure, andaspects of the apparatus 6100 may be positioned on the vehicle, on anexternal device at least selectively in communication with the vehicle,on a cloud server, and/or on a web application.

The example apparatus 6100 includes a vehicle communication circuit 6102that interprets vehicle communications data 6116, which may be datacollected from the vehicle and/or data to be provided to the vehicle.The example apparatus 6100 further includes a visualization circuit 6104that generates visualization data 6118 in response to the vehiclecommunications data 6116. Example visualization data 6118 includes afirst network identifier (e.g., identifying a network zone, end point,or other network identifier for corresponding data) and a second networkidentifier. Example visualization data 6118 can include networkidentifiers corresponding to each of at least two distinct network zonesof the vehicle, and/or each of at least two distinct end points of thevehicle. An example network identifier includes an ethernet basedprotocol and/or a CAN based protocol. Another example network identifierincludes one or more of a cellular based protocol, a WiFi basedprotocol, and/or a Bluetooth based protocol.

The example apparatus 6100 further includes a display interface circuit6106 that transmits the visualization data 6118, providing storedvisualization data 6122 and/or providing the visualization data 6118 toan electronic display 6112. The transmission of the visualization data6118 may include any one or more operations selected from the operationssuch as: transmitting the visualization data 6118 from the vehicle to atool; transmitting the visualization data 6118 from the vehicle to acloud server; transmitting the visualization data 6118 from the vehicleto a display device (e.g., an electronic display 6112 such as a vehicledisplay, a service tool, an external computing device such as anoperator device, a service device, a manufacturer device, a fleet owneror service device, a vehicle communications administrator device, and/ora third-party device, etc.); transmitting the visualization data 6118from a cloud server to a tool; transmitting the visualization data 6118from a cloud server to a display device; and/or transmitting thevisualization data 6118 from a first cloud server to a second cloudserver (e.g., allowing separate storage criteria for the storedvisualization data 6122 between the cloud servers, includinganonymization of data, aggregation of data, compartmentalization ofaspects of the data, etc.). In certain embodiments, transmission of thevisualization data 6118 may include transmitting the visualization data2108 to an on-vehicle storage (e.g., a dedicated memory space availablefor the stored visualization data 6122 for later access, requestedaccess, and/or later transmission to an off-vehicle location), and/or toa closely coupled storage (e.g., a USB device coupled to the vehicle, toa mobile device such as an operator's mobile phone, and/or to acomputing device in close-range wireless communication such as a WiFi orBluetooth connection). Additionally or alternatively, the transmissionof the visualization data 6118 may include any one or more operationsselected from the operations such as: storing the visualization data6118 on a shared storage of the vehicle; storing the visualization data6118 on a shared storage of the vehicle, and selectively transmittingthe stored visualization data 6122 to an external device; transmittingthe visualization data 6118 to a secured cloud storage; and/ortransmitting the visualization data 6118 to a secured cloud storage, andproviding selected access to the stored visualization data 6122 to amonitoring tool, an external application, a service tool, and/or a userdevice.

An example apparatus 6100 includes an electronic display 6112 thatinterprets and displays the visualization data 6118. An exampleelectronic display 6112 accesses the stored visualization data 6122 anddisplays at least a portion thereof, and/or a processed visualizationelement determined from the visualization data 6118 and/or storedvisualization data 6122. Example visualization data 6118 includestopology data corresponding to a network topology of the first networkand/or second network (e.g., depicting the network(s) and/or selectedend points associated with each of the networks). The topology data mayinclude a visual representation, a table listing, or other visualizationof the topology data.

An example visualization circuit 6104 is further structured to includeportion of meta-data of the vehicle communications data 6116 in thevisualization data 6118. Example and non-limiting meta-data of thevehicle communications data 6116 includes data such as a source address,destination address, time stamp, vehicle operating condition or statecondition, fault code information, status parameters for end points,flows, applications, and/or vehicle functions, or the like. In certainfurther embodiments, meta-data of the vehicle communications data 6116includes information relating to the trajectory of the vehiclecommunications data 6116 through the vehicle network, for example framedata related to an originating communication (e.g., frame data from acommunication on a first network 6108, where communication isencapsulated and passed to the vehicle communication circuit 6102 fromthe second network 6110), processing information for a payload and/orframe of the vehicle communications data 6116 (e.g., processingoperations performed on the payload and/or the frame of thecommunication, for example allowing reverse calculation of theprocessing, an up-sampling and/or down-sampling description, or thelike). In certain embodiments, the meta-data may have predeterminedvalues, for example a first data value associated with a firstprocessing operation (e.g., filtering, a resolution change, etc.), asecond data value associated with a second processing operation, wherebythe meta-data communicates the processing operation (or otheroperations) according to the value of selected portions (e.g., specifiedbits) of the vehicle communications data 6116.

An example apparatus 6100 includes a monitoring input circuit 6114 thatinterprets a data filtering value 6120 (e.g., a description of filteringoperations, such as: a selection of certain end points and/or localcommunicating devices; a selection of certain network zones;communications meeting specified criteria; a down-sampling descriptionfor selected communications; communications relating to off-nominalconditions such as end points, flows, vehicle functions, and/orapplications having an associated fault value, and/or communicationsrelating to end points having lost packets, high or low expectedcommunication rates, etc.). Example and non-limiting data filteringvalues 6120 include a network address association, a vehicle controldevice association, a vehicle system association, a network protocoltype, an end point identifier, a data type, an application association,and/or a flow association. Example and non-limiting data filteringvalues 6120 include a reference to a system, such as an engine system, asteering system, a braking system, a fuel system, a prime mover system,an anti-lock braking system, a traction control system, and/or adrivetrain control system. Still further example and non-limiting datafiltering values 6120 include a reference to a system such as a securitysystem, a lighting system, a safety system, an environmental controlsystem, an ADAS, and/or an infotainment system.

The example apparatus 6100 includes the visualization circuit 6104filtering, based at least in part on the data filtering value 6120,portions of the vehicle communications data 6116 to generate thevisualization data 6118. In certain embodiments, the data filteringvalue 6120 may be provided in a policy 1606, communicated from anexternal device 1618, and/or received through a user interface operated(e.g., by the display interface circuit 6106) on an electronic display6112, external tool 6114, and/or a user device such as a device of avehicle owner or operator, service personnel, manufacturer, fleet owner,fleet service personnel, vehicle communications administrator, and/or aninteraction with a cloud-based or web-based application.

Referencing FIG. 63, an example user interface to retrieve and filtervehicle communications data 6116 is depicted. The example user interfacemay be implemented on an external device, web application, cloud-basedapplication, external tool, or the like. In the example of FIG. 63,“Switch 0” corresponds to a first network zone, and “Switch 1”corresponds to a second network zone, allowing a user to select endpoints from each network zone that are to be monitored. In the example,filter selections allow for reduction from monitored end points (e.g.,selections on the left side) according to filtering criteria, such asincluding only selected end points, flows, applications, etc.(selections on the right side). In the example of FIG. 63, monitoredparameters may be further down-sampled (selections at the bottom).Further in the example of FIG. 63, a selected mirroring timeout may beset (e.g., where monitoring is performed using port mirroring). Theexample user interface of FIG. 63 illustrates certain aspects of thenetwork monitoring and filtering operations described herein, and is notlimiting to the present disclosure.

An example apparatus 6100 includes the visualization data 6118 includinga traffic monitoring visualization. For example, a traffic monitoringvisualization can provide a visualization corresponding to one or moreof: an end point on one of the first network or the second network(e.g., showing incoming and/or outgoing traffic from the end point); avehicle system; an application; a flow; a vehicle controller; a vehiclefunction; a selected one of the first network or the second network; ora port of one of the first network or the second network. An examplevisualization data 6118 includes a port counter visualization, forexample displaying messaging traffic corresponding to a port (a physicalport or a logical port) of one of the network zones. An examplevisualization data 6118 includes an end point data flow monitoringvisualization, for example displaying messaging traffic corresponding toan end point of one of the network zones.

Referencing FIG. 64, an example visualization data 6118 is depictedincluding a traffic monitoring visualization. The example of FIG. 64depicts network traffic (e.g., messages, bits, etc.) for a first endpoint 6402 and a second end point 6404. The example of FIG. 64 is anon-limiting example, and traffic monitoring may be depicted in anymanner, and may be organized according to any grouping, such asper-network, per-port, all traffic associated with an application, alltraffic associated with a flow, all traffic associated with a vehiclefunction, all traffic associated with a service group, etc.

An example apparatus 6100 includes the visualization data including anetwork activity profile, where the network activity profile is providedfor one or more of: an end point on one of the first network or thesecond network; a vehicle system; an application; a flow; a vehiclecontroller; a vehicle function; a selected network zone; and/or aselected port of one of the network zones.

Referencing FIG. 65, an example visualization data 6118 is depictedincluding a network activity profile. The example of FIG. 65 depictsnetwork bandwidth utilization for a selected network zone, with a numberof utilization plots 6502, 6504, 6506, 6508, each associated with an endpoint of the selected network zone. Referencing FIG. 66, an examplevisualization data 6118 is depicted including a network activity profilefor a selected network zone. The example of FIG. 65 depicts a totalactivity for the network zone at the top, a network bandwidthutilization for particular devices (e.g., ISL 0, ISL 1) in the middle,and network bandwidth utilization for a vehicle controller (e.g., aHeads-up display and head unit) at the bottom, with the networkbandwidth utilization for the vehicle controller further depictingutilization for a number of specific devices broken out (e.g., variouscameras, in the example). The example of FIGS. 65 and 66 arenon-limiting, and network activity profile data may be determined anddisplayed in any manner, and further may be grouped and/or sub-groupedin any manner, including by end point, flow, application, vehiclefunction, vehicle controller, etc.

An example vehicle communication circuit 6102 interprets the vehiclecommunications data 6116 by performing one or more operations such as:interpreting the vehicle communications data 6116 from a policy 1606stored on a memory positioned on the vehicle and communicatively coupledto the vehicle communication circuit 6102; receiving the vehiclecommunications data 6116 from a service tool communicatively coupled tovehicle communication circuit 6102; receiving the vehicle communicationsdata 6116 from an application communicatively coupled to the vehiclecommunication circuit 6102; or receiving the vehicle communications data6116 from a monitoring tool communicatively coupled to the vehiclecommunication circuit 6102.

In certain embodiments, retrieving vehicle communications data 6116including traffic monitoring, network activity, and/or messagescorresponding to an end point of a network zone and/or corresponding toa port of a network zone includes mirroring traffic from a first port ofa network zone to a second port of the network zone, and monitoring thesecond port of the network zone to determine the vehicle communicationsdata 6116. For example, a first port of the second network zone 6110 maycorrespond to an end point to be monitored, where the operation toretrieve the vehicle communications data 6116 includes an operation tomirror the first port of the second network zone 6110 to a second portof the second network zone 6110 (e.g., where the vehicle communicationscircuit 6122 and/or a monitoring tool such as external tool 6114 arecommunicatively coupled to the second port), and monitoring the secondport of the second network zone 6110 to determine the vehiclecommunications data 6116.

Referencing FIG. 67, an example visualization data 6118 is depictedincluding data flows between selected network participants (e.g., endpoints, flows, applications, vehicle controllers, etc.). The example ofFIG. 67 depicts data flows between selected end points, in the exampledepicting data flows with the “EP1” (e.g., an end point, such as a headunit) and the other end points (e.g., EP3, EP5, EP10, in the example,such as an ADAS related component, a parking controller, etc.). Theexample of FIG. 67 allows monitoring of the network to determine ifexpected data flows are occurring, if off-nominal data flow isoccurring, and the like. Referencing FIG. 68, an example visualizationdata 6118 is depicted showing total network activity for a selectednetwork zone (at the top), and data pathing from a selected end point toother end points (the data path at the bottom) in the system. In theexample, user interface elements may be provided, for example allowingselection of a time (top depiction) that is utilized for the datapathing depiction at the bottom, allowing for selection of the targetend point (e.g., EP1 at the left), and/or whether transmission, receipt,or both, are depicted. In certain embodiments, the visualization data6118 may be presented as a user interface, for example allowing a userto select components and have the related data flows depicted. It can beseen that a visualization such as those depicted in FIGS. 67 and 68 canbe utilized to confirm expected operations, to diagnose issues (e.g.,degraded operation of a component, diagnoses of a network issue, and/ordetect off-nominal operating conditions such as those indicated bycommunication between components that more substantially communicateduring certain off-nominal operating conditions). Additionally oralternatively, a visualization such as that depicted in FIG. 67 can beutilized to: improve network topology design, hardware selection, and/orprotocol selection; to consolidate applications, flows, vehiclefunctions, etc. on vehicle controllers (e.g., to reduce network trafficrequirements); and/or to identify potential redundant or unnecessarynetwork communications.

Referencing FIG. 62, an example local address table 6200 is depicted,schematically depicted configuration information consistent with variousembodiments of the present disclosure. The example local address table6200 may be part of the policy 1606 and/or a configuration file (e.g.,accessible in whole or part by interface circuit(s) and/or aconfiguration circuit). The local address table 6200 may be provided asa data structure in a memory location accessible to the interfacecircuit(s), configuration circuit(s), and/or other implementingcomponents described throughout the present disclosure. The localaddress table 6200 may be provided as a distributed data structure, withportions of the local address table 6200 provided as a data structure inmemory location(s) accessible to the implementing components. Theexample local address table 6200 is depicted schematically to provide anillustration of the type of local address information that may beutilized to implement aspects of the present disclosure, but the detailsof the stored information and the organization of data structuresimplementing the local address table 6200 may be configured according tothe implemented embodiments. The example local address table 6200includes an end point identifier 6202, which may be a local identifierof end points present in the system. In a further example, non-local endpoint identifiers (not shown) may further be included, for example toallow external devices to reference end points using anindustry-standard terminology, or other selected terminology. Theexample local address table 6200 includes a network zone identifier6204, for example indicating which network zone the end point isconsidered to be a part of. The example address table 6200 furtherincludes a local address value 6206, for example indicating how therespective end point is addressed on the appropriate network zone. Incertain embodiments, the local address value 6206 may be a TCP/IPaddress, a port number, or other identifier. In certain embodiments, forexample on a logical bus architecture such as a CAN bus, the localaddress value 6206 may include a message identifier, such as a valueincluded in a message that indicates the intended recipient (or thesource) of messages to or from the end point. The example local addresstable 6200 includes an external address value 6208, which may, forexample, include an address utilized to identify the end point byexternal devices.

The utilization of the external address value 6208 allows for externaldevices to abstract knowledge of the end point, including localaddressing and/or associated network zones, from operations to utilizeand/or collect data from the corresponding end points. It can be seenthat further information may be included in a local address table 6200,such as additional external address values (e.g., to allow for multipleexternal addresses to associate with a given end point of the system),and/or the inclusion of one or more additional non-local end pointidentifiers (e.g., to allow for multiple industry standards, proprietarynomenclature, informal nomenclature, etc., to successfully associatewith a given end point of the system). In certain embodiments, one ormore of the external addresses 6208 and/or non-local end pointidentifiers may further be associated with versions (e.g., interfaceversions, vehicle model descriptions, etc.), allowing for theimplementing components using the local address table 6200 to interpretdata commands and/or requests from external applications, algorithms,etc. to properly associate a desired end point to the data commandand/or request, as changes occur within the vehicle (e.g., end pointsmove between network zones and/or addresses) or external to the vehicle(e.g., external applications are updated for updated vehicleconfigurations that are no longer applicable to the specific vehicle ofthe system).

It can be further seen that the utilization of the local address table6200 allows for multiple addressing support for end points of thevehicle, for example providing both IPv4 and IPv6 addressing for endpoints of the vehicle. In certain embodiments, the local address table6200 can be expanded, or alternatively a separate data structuremaintained, allowing for association of end points with applications,flows, vehicle functions, vehicle controllers, APNs, external datarouting paths, network zone trajectories, or the like. The example localaddress table 6200 may be utilized in a network address translation(NAT) operation. Accordingly, a given application such as “routemanagement” can be associated with particular end points of the vehicle,and the associations can survive through a movement of the end point(e.g., from one network zone to another network zone). The utilizationof a local address table 6200, and/or extended or alternate datastructures as described herein, allows for configuration of priorities,permissions, subscription management (both publishing of services andsubscribing to services), and/or any other communication regulatingactivities as set forth herein.

In certain embodiments, the local address table 6200 can be expanded, oralternatively a separate data structure maintained, allowing foraddresses of external devices to be configured according to end points,applications, flows, vehicle functions, and/or vehicle controllers. Forexample, a given vehicle function may be allowed access to a givenexternal resource (e.g., a routing function that accesses an externalresource having maps, traffic reporting, etc.), with an associatedexternal address associated with the vehicle function that providesaccess to the external resource. In the example, other vehicle functionsmay not be allowed access to the given external resource, with anassociated external address associated with those vehicle functions(and/or with a lacking association for those other vehicle functions,depending upon the implementation), such that when those other vehiclefunctions request access to the external resource, a default address,protected space, null communication, or other selected behavior isinstead implemented. Accordingly, a first application of the vehiclerequesting accessing to an external resource, such ashttps://www.google.com may receive a typical expected access to theexternal IP address corresponding to the Google website, where a secondapplication of the vehicle requesting access to the same externalresource may receive an access denied indication, a default externalresource indication (e.g., a cloud-based resource in a protected spaceindicating the requested resource is not permitted), or other selectedresponse from the system. Accordingly, the local address table 6200,and/or an expanded, extended, or alternate version thereof, may beutilized as a local DNS and/or an external DNS. In certain embodiments,for example where access to an external resource is requested, where theexternal DNS does not have an address for the resource, and where apermission to the requestor (e.g., end point, application, flow, vehiclefunction, and/or vehicle controller) is not denied to access theexternal resource, an off-vehicle external DNS (e.g., on a cloud server,from an internet provider, etc.) may be accessed to provide the externaladdress. In certain embodiments, the on-vehicle external DNS may beupdated based on an address retrieved from the off-vehicle external DNS.

Referencing FIG. 70, an example procedure 7000 to transmit visualizationdata is schematically depicted. The example procedure 7000 includes anoperation 7002 to interpret vehicle communications data, an operation7004 to generate visualization data in response to the vehiclecommunications data, and an operation 7006 to transmit the visualizationdata.

Referencing FIG. 71, an example procedure 7100 to transmit visualizationdata is schematically depicted. The example procedure 7100 includes anoperation 7002 to interpret vehicle communications data, an operation7102 to interpret a data filtering value, and an operation 7104 tofilter at least a portion of the vehicle communications data based, atleast in part, on the data filtering value. The example procedure 7100further includes an operation 7004 to generate visualization data inresponse to the vehicle communications data, and an operation 8006 totransmit the visualization data.

Referencing FIG. 77, an example procedure 7700 to transmit visualizationdata to an external device and/or a user device is schematicallydepicted. The example procedure 7700 includes an operation 7702 tointerpret a policy from an external device, and an operation 7704 toconfigure network interface circuit(s) in response to the policy. Theexample procedure 7700 includes an operation 7706 to regulatecommunications on the vehicle (inter-network and/or intra-networkcommunications), and an operation 7708 to determine source and/ordestination definitions for data collection. The example procedure 7700includes an operation 7710 to determine visualization data in responseto the vehicle communications data (e.g., collected in response to thepolicy, and the source/destination definitions for the collected data),and an operation 7712 to transmit the visualization data (e.g., to anexternal device, user device, data storage, application, etc.).

Referencing FIG. 78, an example procedure 7702 to interpret a policy forconfiguring regulation of inter-network and/or intra-networkcommunications is schematically depicted. The example procedure 7702includes an operation 7802 to generate a policy interaction code, anoperation 7804 to accept policy input value(s) in response to the policyinteraction code, and an operation 7806 to generate a policy in responseto the accepted input value(s). The example procedure 7702 furtherincludes an operation 7808 to communicate the generated policy to a CNDusing an external device.

Referencing FIG. 72, an example system 7200 includes a vehicle 102having a first network zone 5612 and a second network zone 5614 isdepicted, where the first network zone 5612 and the second network zone5614 are of different types. The example of FIG. 72 includes a CND 108interposed between the network zones 5612, 5614. The example CND 108includes a policy manager circuit 5602 that interprets a policy 5606including a network regulation description, a configuration circuit 5604that configures a first network interface circuit 5608 in response tothe network regulation description, where the first network interfacecircuit 5608 regulates communications between end points of the firstnetwork zone 5612 and end points of the second network zone 5614.Additionally or alternatively, the configuration circuit 5604 configuresa gatekeeper interface circuit 7202 in response to the networkregulation description, where the gatekeeper interface circuit 7202regulates communications between end points of at least one of thenetwork zones 5612, 5614 and external communication portal(s) and/or theexternal device 5618. An example first network interface circuit 5608includes a CEG, where the first network zone 5612 is not a primarynetwork (e.g., the first network zone 5612 is a CAN network, and thesecond network zone 5614 is an ethernet network), and where the firstnetwork interface circuit 5608 is communicatively coupled to a port ofthe second network zone 5614 to send and receive communications that arepassed between the network zones 5612, 5614.

Referencing FIG. 73, an example network regulation description 7304includes a data request permission description 7306 including datavalues 7310 associated with data requestors 7308 (e.g., end points eachon one of the network zones 5612, 5614). An example first networkinterface circuit 5608 regulates communications between end points ofthe first network zone 5612 and the second network zone 5614 in responseto the data request permission description 7306, for example limitingassociated data requestors 7308 to authorized data values 7310, and/orpreventing associated data requestors 7308 from accessing unauthorizeddata values 7310. In certain embodiments, the first network interfacecircuit 5608 further regulates communications between end points of thefirst network zone 5612 (e.g., from a first end point to a second endpoint, both on the first network zone 5612) in response to the datarequest permission description 7306.

An example system 7200 further includes the configuration circuit 5604configuring the second network interface circuit 5610 in response to thenetwork regulation description, where the second network interfacecircuit 5610 regulates communications of end points of the secondnetwork zone 5614. Again referencing FIG. 73, an example second networkinterface circuit 5610 regulates communications between end points ofthe second network zone 5614 and the first network zone 5612 in responseto the data request permission description 7306, for example limitingassociated data requestors 7308 to authorized data values 7310, and/orpreventing associated data requestors 7308 from accessing unauthorizeddata values 7310. In certain embodiments, the second network interfacecircuit 5610 further regulates communications between end points of thesecond network zone 5614 (e.g., from a first end point to a second endpoint, both on the second network zone 5614) in response to the datarequest permission description 7306.

An example system 7200 further includes the configuration circuit 5604configuring a gatekeeper interface circuit 7202 in response to thenetwork regulation description 7304, where the gatekeeper interfacecircuit 7202 regulates communications between end points of both thefirst network zone 5612 and the second network zone 5614 with anexternal device 5618. The example external device 5618 may be coupled tothe first network zone 5612, the second network zone 5614, or both.Additionally or alternatively, the external device 5618 may be coupledto a transceiver (not shown) of the vehicle 102, which may be acellular, WiFi, and/or Bluetooth transceiver. In certain embodiments,the transceiver may be communicatively coupled to a network zone, forexample as a port on one of the network zones. In certain embodiments,the first network zone 5612 is a non-primary network zone, the secondnetwork zone 5614 is a primary network zone, and the transceiver iscommunicatively coupled to the second network zone 5614. In a furtherexample embodiment, the second network zone 5614 is an ethernet network,and the transceiver is coupled to the second network zone 5614 bycommunicating with the second network interface circuit 5610 through aport of a CES including the second network interface circuit 5610.

Example and non-limiting external devices 5618 include one or more of: acloud server based application, a web based application, and/or a mobiledevice application. Again referencing FIG. 73, an example data requestpermission description 7306 includes a data access permission 7314associated with each one of a number of external communicators 7312.Example external communicators 7312 include identified external devices5618, external applications, external flows, external entities (e.g.,service, manufacturer, owner, operator, etc.), external addresses, etc.Example and non-limiting data access permissions 7314 includepermissions to communicate with particular end points, flows,applications, vehicle functions, network zones, vehicle controllers, andthe like. In certain embodiments, the data access permissions 7314 maybe distinct for transmitted and received communications—for example agiven external communicator 7312 may not have permissions to requestdata from a first end point on the vehicle, but the first end point onthe vehicle may have permissions to send data to the given externalcommunicator 7312. An example data request permission description 7306includes data access permissions associated with one or more of: anexternal device; an external communicator; a flow associated with an endpoint, external device, and/or external communicator; a vehicle functionassociated with an end point, external device, and/or externalcommunicator; and/or an application associated with an end point,external device, and/or external communicator. Example and non-limitingdata access permissions 7314 include one or more of: an ability torequest, transmit, and/or publish data; an ability to request, transmit,and/or particular data values; and/or an external communicationbandwidth limitation (e.g., a data rate, aggregated data amount per unittime, and/or a share of an available bandwidth). An example system 7200further includes the gatekeeper interface circuit 7202 regulatingcommunications between end points of the network zones 5612, 5614 withexternal devices 5618 (and/or external communicators 7312) in responseto the data request permission description 7306 and/or the data accesspermissions 7314.

An example gatekeeper interface circuit 7202 further regulatescommunications with external device(s) 5618 (and/or externalcommunicator(s) 7312) in response to one or more of: a flow associatedwith the regulated communication(s) (e.g., adjusting permissions basedon a priority of the associated flow, a role of the associated flowand/or current operation conditions, etc.); a data type associated withthe regulated communication(s) (e.g., prioritizing or de-prioritizingcertain data types, limiting certain data types to certain communicationconditions such as availability of high data rate communications, typingdata according to criteria such as age of the data and adjustingpermissions accordingly, etc.); a data service provider associated withthe regulated communication(s) (e.g., configuring data rate, bandwidth,and/or aggregate data values in response to an associated data serviceprovider for the data); a vehicle function associated with the regulatedcommunication(s) (e.g., prioritizing certain vehicle functions); and/ora connection type of a communicative coupling with the externaldevice(s) 5618 (and/or external communicator(s) 7312) (e.g., allowingfor greater communication rates when a high rate and/or low cost dataconnection is available).

An example system 7200 includes a configuration circuit 5604 thatreceives a policy update (e.g., from the policy manager circuit 5602)including a change to the network regulation description 7304, andupdating the configuration(s) of the first network interface circuit5608, second network interface circuit 5610, and/or gatekeeper interfacecircuit 7202 in response to the change to the network regulationdescription 7304. In a further example, the policy manager circuit 5602interprets an authorization associated with the policy update, forexample based on a permission of an external device 5618 and/or externalcommunicator 7312 providing the policy update. The example policymanager circuit 5602 suppresses the policy update, in whole or part, inresponse to the authorization indicating the requesting unit (e.g., theexternal device 5618 and/or external communicator 7312) is notauthorized to make the change to the network regulation description ofthe policy update. In certain embodiments, policy manager circuit 5602may additionally or alternatively provide one or more policynotifications 5620, to the requesting unit and/or to other externaldevices 5618 or external communicators 7312, in response to suppressingor partially suppressing the policy update (e.g., reference FIG. 56 andthe related description). Example and non-limiting requesting unitsinclude one or more of: an entity associated with the policy update; anapplication associated with the policy update; a flow associated withthe policy update; a vehicle function associated with the policy update;an identifier of the external device communicating the policy update;and/or an identifier of an external communicator associated with thepolicy update.

Again referencing FIG. 72, an example policy manager circuit 5602interprets a policy 5606 including a network usage permissiondescription 7404 (reference FIG. 74). An example network usagepermission description 7404 includes an external data access description7406, where the configuration circuit 5604 further configures thegatekeeper interface circuit 7202 in response to the external dataaccess description 7406, and where the gatekeeper interface circuit 7202regulates communications with an external device 5618 in response to theexternal data access description 7406. An example external data accessdescription 7406 includes external access permission(s) 7414 associatedwith external communicator(s) 7412, such as identified external devices5618, external applications, external flows, external entities (e.g.,service, manufacturer, owner, operator, etc.), external addresses, etc.In certain embodiments, external communicators(s) 7412 include one ormore local communicating devices requesting an external communication,such as a flow of the vehicle, an application, a network zone of thevehicle, an end point of a network zone, or the like. For example, anexample gatekeeper interface circuit 7202 regulates externalcommunications based on a flow association of a communicating one of theend points of the first network zone and/or the second network zone(e.g., limiting external communications to permitted communicationsaccording to the external access permission(s) 7414, and/or allowingexternal communications that are not excluded by the external accesspermission(s) 7414). An example gatekeeper interface circuit 7202regulates external communications based on an application association ofa communicating device (e.g., an external device 5618, and/or an endpoint), for example limiting external communications to permittedcommunications according to the external access permission(s) 7414and/or allowing external communications that are not excluded by theexternal access permission(s) 7414. An example gatekeeper interfacecircuit 7202 regulates external communications based on a network zoneassociation of a communicating device (e.g., a network zone associatedwith an end point that requests the external communication, or sourcezone; and/or that is the target of an external communication, ordestination zone), for example limiting external communications topermitted communications according to the external access permission(s)7414 and/or allowing external communications that are not excluded bythe external access permission(s) 7414. In certain embodiments, thefirst network zone and the second network zone may be separate virtuallocal area networks of the vehicle, and may have separate externalaccess permissions 7414.

An example policy 5606 includes an external data quantity description(not shown), where the configuration circuit 5604 configures thegatekeeper interface circuit 7202 in response to the external dataquantity description. An example external data quantity descriptionincludes a data limit for an application, and where the gatekeeperinterface circuit further regulates external communications based on anassociation of a communicating device with the application. Anapplication may be a vehicle operation related application (e.g., anapplication operating on the vehicle, and/or operating on an externaldevice with communicative interactions with the vehicle) or anapplication not related to vehicle operation (e.g., a infotainmentapplication, an operator application, web browsing utilizing a networkzone of the vehicle, a third party application communicating with thevehicle, etc.). An example external data quantity description includes adata limit for an end point of one of the network zones, and thegatekeeper interface circuit regulates communications based on a sourceor a destination end point of regulated communications. An exampleexternal data quantity description includes a data limit for a flow, andthe gatekeeper interface circuit regulates external communications basedon an association of a communicating device with the flow.

Example and non-limiting data limits include one or more of: an amountof communicated data corresponding to a selected time period (e.g., MBper hour, GB per month, etc.); an amount of communicated datacorresponding to a selected vehicle operating condition (e.g., MB pertrip; data rate during idling operation; data rate at rated operation;data rate during high transient operation; etc.); an amount ofcommunicated data corresponding to a data provider associated with theapplication, end point, and/or flow; a bandwidth share of thetransceiver utilized for the communications; a bandwidth volume of thetransceiver utilized for the communications; a bandwidth share of achannel of the transceiver (e.g., where the transceiver includes morethan one channel, where the bandwidth share is limited for channel(s)servicing external communications for the application, end point, and/orflow); and/or a bandwidth volume of a channel of the transceiver (e.g.,where the transceiver includes more than one channel, where thebandwidth volume is limited for channel(s) servicing externalcommunications for the application, end point, and/or flow).

Referencing FIG. 75, an example network usage permission description3004 includes a network utilization description 7502 corresponding to anetwork zone 7504, and a communicating device description 7506corresponding to a local communicating device, such as an end point, aflow, a vehicle function, sensor device, and/or an application. In theexample, the gatekeeper interface circuit 7202 further regulatesexternal communications based on the network utilization description7502, and an associated communicating device (e.g., corresponding to thecommunicating device description 7506) with the regulated communication.An example network utilization description 7502 includes determining apriority 7508, an associated flow 7510, an associated vehicle function7512, an associated application 7514, and/or an associated condition orevent 7516 (e.g., a triggering event to implement an aspect of thepolicy 5606, vehicle or other conditions to be present to allowimplementation of the aspect of the policy 5606, and/or vehicle or otherconditions which, if present, adjust or suppress an aspect of the policy5606) with the communicating device to regulate the externalcommunications. The network utilization description 7502 may include oneor more of: a bandwidth of the network zone 7504 available to beutilized to support external communications; a data rate on the networkzone 7504 available to be utilized to support external communications; abandwidth limitation of the network zone 7504 (e.g., where externalcommunications would cause a general exceedance, they may be suppressedor reduced); and/or a data rate limitation of the network zone 7504(e.g., where external communications would cause a general exceedance,they may be suppressed, reduced, or delayed). In certain embodiments,priorities 7508 or other information related to the externalcommunications may be compared with priorities of on-vehiclecommunications utilizing the network zone, and an external communicationmay take priority over the on-vehicle communication, which may besuppressed, reduced, or delayed until the external communication isserviced. In certain embodiments, service requirements (e.g., QoSparameters) for on-vehicle end points, flows, applications, vehiclefunctions, etc. (e.g., local communicating devices), may be consideredin determining an external communication permission, and the externalcommunication may be allowed while the service requirements can be met.

Referencing FIG. 76, an example procedure 7600 to regulate extra-vehiclecommunications is schematically depicted. The example procedure 7600includes an operation 7602 to interpret a policy including a networkusage permission description and/or an external data access description,an operation 7604 to configure network interface circuit(s) in responseto the network usage permission description, and an operation 7606 toregulate intra-network and/or inter-network communications using thenetwork interface circuit(s). The example procedure 7600 includes anoperation 7608 to configure a gatekeeper interface circuit in responseto external data access description, and an operation 7610 to regulateextra-vehicle communications using the gatekeeper interface circuit.

Referencing FIG. 79, an example system for controlling inter-networkcommunications, intra-network communications, and/or extra-vehiclecommunications utilizing a scheduled policy scheme is schematicallydepicted. The example system includes a vehicle 102 having at least onenetwork (a first network zone 7902 and a second network zone 7904, inthe example of FIG. 79), a policy manager circuit 7906 that interprets apolicy 7908 including external data communication parameters, such as anexternal data routing description and/or an external data servicedescription. The example system includes a configuration circuit 7910that configures a gatekeeper interface circuit 7920 in response to thepolicy 7908, and that regulates communications between end points of thenetwork zones 7902, 7904 and an external communication portal 7916. Theexternal communication portal 7916 is selectively coupled to an externaldevice 7918. The external communication portal 7916 includes an externalcommunication portal 7916 as set forth herein, including at least anyone or more of the examples depicted in relation to FIG. 41 and therelated description. In the example of FIG. 79, the gatekeeper interfacecircuit 7920 is depicted as coupled to the external communicationportal(s) 7916. However, the gatekeeper interface circuit 7920 mayregulate communications in any manner, for example by furtherconfiguring the network interface circuit(s) 7912, 7914 to allowselected communications, and/or communications having a selectedprocessing, encapsulation, data file format, communication protocol,authorization, and/or any other regulation descriptions as describedthroughout the present disclosure. In the example of FIG. 79, the policymanager circuit 7906, configuration circuit 7910, and network interfacecircuit(s) 7912, 7914 are depicted as positioned on the CND 108. Asdescribed elsewhere herein, the CND 108 may provide instructions orotherwise regulate components, and the depicted components (and/or theCND 108) may be distributed elsewhere on the vehicle 102 separate, inwhole or part, from the CND 108.

Referencing FIG. 80, an example policy 7908 includes one or more of asecondary policy value 8006, a primary policy value 8004, and/or adefault policy value 8002. An example configuration circuit 7910configures the gatekeeper interface circuit 7920 in response to thedefault policy value 8002 if there is no primary policy value 8004and/or secondary policy value 8006 present (and/or if the primary policyvalue 8004 and/or secondary policy value 8006 are not valid), inresponse to the primary policy value 8004 if there is no secondarypolicy value 8006 present (and/or valid), and utilizing the secondarypolicy value 8006 if present (and valid). An example configurationcircuit 7910 configures the network interface circuit(s) 7912, 7914 inresponse to the default policy value 8002 if there is no primary policyvalue 8004 and/or secondary policy value 8006 present, in response tothe primary policy value 8004 if there is no secondary policy value 8006present, and utilizing the secondary policy value 8006 if present. Anexample configuration circuit 7910 applies the policies if present inthe order described (e.g., using the secondary policy value 8006 ifpresent, and ignoring any remaining policy values 8004, 8002). Anexample configuration circuit 7910 applies more than one policy value ifthe policy values are compatible and/or consistent (e.g., applying asecondary policy value 8006, and applying portions of the primary policyvalue 8004 that are not in conflict with the secondary policy value8006). In the example of FIG. 80 the default policy value 8002 may be apermanent storage policy (e.g., a policy stored with main executableinstructions stored on a computer readable medium that includeinstructions for at least a portion of operations of the CND 108 and/orassociated circuits therefore). In certain embodiments, the primarypolicy value 8004 and/or the secondary policy value 8006 include policyvalues that are readily updated in real time, for example stored as datafiles (e.g., provided at selected memory locations, selected OS logiclocation, according to certain naming conventions, and/or stored withselected header information, metadata, or the like identifying eachpolicy value as a primary policy value 8004 or a secondary policy value8006), stored as a part of a calibration set, trim set, or the like.

An example primary policy 8004 is a tool supplied policy, such as amanufacturer tool, OEM tool, service tool, or the like. In certainembodiments, the secondary policy value 8006 is a downloaded policyvalue, for example a policy value received from an external devicethrough an external communications portal, and from a web based tool,cloud application, or the like. The recited examples are non-limiting,and any of the policy values may be received from any externalcommunications portal. An example implementation includes the defaultpolicy value 8002 provided at a time of initialization of the CND 108 orrelated control components (e.g., a first image file applied to acontroller housing executable portions of the CND 108, policy managercircuit 7906, or the like), and which is not generally updated except,for example, as a part of an entire instruction set update (e.g.,updating the executable instructions provided for the CND 108 and/orportions thereof). An example implementation includes the primary policyvalue 8004 provided at a time of manufacture, assembly, or other initialpre-mission service or assembly operation on the vehicle. An exampleimplementation includes the secondary policy value 8006 provided as adownloaded operation, and/or provided during a service operation,trimming and/or application configuration operation (e.g., by an OEM,body builder, or the like). The utilization of the scheduled policyvalues 8002, 8004, 8006 allows for the implementation of a minimumcapability (and/or lowest risk) policy, providing sufficient capabilityfor devices of the vehicle to communicate externally, for example todownload and/or act on a replacement policy such as a primary policyvalue 8004 and/or secondary policy value 8006. The utilization of thescheduled policy values allows for various stakeholders in amanufacture, remanufacture, re-configuration, service, sale or transfer,mission change, or other vehicle related operation to ensure that policyrequirements (e.g., permissions for local communicating devices tocommunicate within a network, across a network, to store data, and/or tocommunicate with external devices) are met, while allowing for ease ofpolicy updates, implementations, and interfaces for third-parties,owner/operators, fleet owners, and the like to adjust policy values andresulting communication regulation operations. The utilization of thescheduled policy values 8002, 8004, 8006 allows for ease of policyupdates, verification, and implementation. The utilization of scheduledpolicy values 8002, 8004, 8006 allows for re-configuration of a policyand/or regulatory response of communications to be adjusted in real timewith a low impact to the mission of the vehicle (e.g., withoutcontroller reset operations, adjustment of primary executableinstruction files, or the like), for example to adjust policies inresponse to regulatory characteristics such as geography (e.g., locationof the vehicle), jurisdiction (e.g., jurisdictional location of thevehicle), and/or operations where direct control of the vehicle may notbe available (e.g., after an accident, towing event, sale or othertransfer, etc.). In certain embodiments, the scheduled policy values8002, 8004, 8006 may be applied by one of a number of devices atdifferent times, for example a default policy value 8002 applied by afirst device, the primary policy value 8004 applied by a second device,and the secondary policy value 8006 applied by a third device. Incertain embodiments, a given external device may apply more than one ofthe scheduled policy values 8002, 8004, 8006, and/or apply a laterversion of one of the scheduled policy values 8002, 8004, 8006 at alater time relative to application of an earlier version. In certainembodiments, more than one version of a given policy value may bepresent (e.g., a secondary policy value 8006) with a selected one of theversions utilized in response to operating conditions (e.g., vehicleoperating conditions, geography, jurisdiction, off-nominal conditionsand/or fault code conditions, etc.). In certain embodiments, a givenpolicy value 8006 may include more than one version of an aspect of thepolicy, for example providing for different data collection operationsfor a given local communicating device, controller, flow, application,end point, etc., an selecting a version of the aspect of the policy inresponse to operating conditions.

Referencing FIG. 81, an example procedure 8100 for regulating network(s)on a vehicle is schematically depicted. The example procedure 8100includes an operation 8102 to utilize, in order and if present, asecondary policy value, a primary policy value, and a default policyvalue. The example procedure 8100 further includes an operation 8104 tointerpret a policy, according to the utilized policy value(s), where thepolicy includes a network regulation description, and an operation 8106to configure network interface circuit(s) in response to the policy. Theexample procedure 8100 further includes an operation 8108 to operate thenetwork interface circuit(s) to regulate network(s) of the vehicle.

An example system includes a CND disposed onboard the vehicle, definedat least in part by an Ethernet switch (e.g., a CES) and/or a CANgateway (e.g., a CEG). The example CND encapsulates at least a portionof a CAN based message from the CAN based network in an Ethernet basedmessage, and/or encapsulates at least a portion of an Ethernet basedmessage from the Ethernet based network in a CAN message. The examplesystem includes a configuration circuit disposed onboard the vehiclethat modifies the CND in response to a configuration command value froma service device external to the vehicle. The configuration circuit maybe disposed on the CES and/or the CEG (in whole or part). The exampleCES includes a number of ports on the ethernet based network, where theconfiguration circuit configures a first port of the number of ports tomirror a second port of the number of ports (e.g., allowing for amonitoring tool, service tool, other external device to monitor thefirst port, and/or allowing operations of the CND to store at least aportion of the data at the first port, thereby monitoring the secondport). An example configuration circuit modifies the CND by adjustingwhich port is the first port (e.g., the monitoring port) and/or thesecond port (e.g., the monitored port).

In an additional or alternative example (e.g., reference FIGS. 45-55 andthe related descriptions), the system includes a service device (e.g.,any external device described throughout the present disclosure)including a CAN message generation circuit that communicates onto theethernet based network and/or the CAN based network, where the CANmessage generation circuit generates a CAN message and transmits the CANmessage to a device (e.g., a local communicating device) onboard thevehicle. The example CAN message generation circuit can transmit a CANmessage regardless of the connectivity of the service device, forexample where the connection is to an ethernet based network, the CND(and/or CEG, CES, gatekeeper interface circuit, and/or a networkinterface circuit) encapsulates the CAN message, passes it through theethernet based network, and de-encapsulates the message as a CAN messageonto the CAN based network.

In an additional or alternative example (e.g., reference FIGS. 45-55 andthe related descriptions), the system includes a service deviceincluding a testing circuit that communicates onto the ethernet basednetwork and/or the CAN based network, where the testing circuitgenerates one or more test command values that collectively test devicesdistributed across more than one network on the vehicle (e.g., a firstdevice on the ethernet based network and a second device on the CANbased network).

[Illustrative Language for CVS 46-48, 72, 77, Include in PCT]

An example system includes a first network zone of a vehicle having afirst interconnected number of end points, and a second network zonehaving a second interconnected number of end points. The example systemfurther includes a converged network device (CND) interposed between thefirst network zone and the second network zone, where the CND isconfigured to regulate communications between end points of the firstnetwork zone and the second network zone.

One or more certain further aspects of the example system are describedfollowing, any one or more of which may be incorporated in certainembodiments. The example system includes the first network zonepositioned in a first risk exposure profile, and the second network zonepositioned in a second risk exposure profile, where the first riskexposure profile is distinct from the second risk exposure profile.Example and non-limiting distinctions between the risk exposure profilesinclude one or more of: a geometric distinction; an environmentaldistinction; a failure mode distinction; a likely risk type distinction;and/or a likely disturbance distinction. The example system includes theCND distributed between a first portion positioned at a first locationin the vehicle, and a second portion positioned at a second location inthe vehicle. In certain embodiments, the first portion of the CNDregulates communications between end points of the first network zoneand the second network zone, and in certain further embodiments thesystem includes a network redundancy circuit that selectively provides aregulation control command, where the second portion of the CNDselectively regulates at least a portion of the communications betweenthe end points of the first network zone and the second network zone inresponse to the regulation control command.

The example system includes the CND having a configurable edge gateway(CEG), and where communications between end points of the first networkzone and the second network zone are routed through the CEG. The examplesystem further includes the CND having an Ethernet switch, where thefirst network zone includes an Ethernet network, and wherecommunications between end points of the second network zone and thefirst network zone are routed through the Ethernet switch. The examplesystem further includes the CEG configured to provide communicationsbetween end points of the first network zone and the second network zoneat a port of the Ethernet switch. Example and non-limiting network typesof the second network zone include one or more of: a Controller AreaNetwork (CAN), a Media Oriented Systems Transport (MOST) network, aLocal Interconnect Network (LIN), a FlexRay network, a Time-TriggeredProtocol (TTP) network, a Low-Voltage Differential Signaling (LVDS)network, an Audio Video Bridging (AVB) compliant network, a customizedversion of any one or more of the foregoing, and/or a proprietaryversion of any one or more of the foregoing. The example system includesa third network zone, where the CEG provides communications between endpoints of the first network zone and the third network zone at a port ofthe Ethernet switch, which may be provided at a shared port withcommunications between of the first network zone and the second networkzone, or which may be a separate port.

The example system includes the CEG configured to encapsulate acommunication from the second network zone into an Ethernetcommunication, and to provide the encapsulated communication to the portof the Ethernet switch. The encapsulated communication includes one ormore of: a payload of the communication; a processed payload of thecommunication; a portion of a frame of the communication; a processedportion of a frame of the communication; the entire frame of thecommunication; and/or the entire frame of the communication, having oneor more portions thereof provided as processed portions. In certainembodiments, the second network zone includes an electrical signal zone.An example CEG further performs analog/digital processing ofcommunications with the second network zone, and/or signal processingoperations of communications with the second network zone. The examplesystem includes the CEG configured to generate a processed payload byperforming one or more of: a unit change of the payload; a bit depthchange of the payload; a normalization of the payload; and/or a timeshift of the payload. The example system includes the CEG configured togenerate a processed portion of a frame of the communication byperforming one or more of: adjusting a time stamp of the communication;applying a time stamp to the communication; adjusting a source indicatorof the communication; and/or adjusting a destination indicator of thecommunication.

The example system includes the second network having a bus topology,and/or the first network having a topology such as: a serial topology, amesh topology, a hub topology, a ring topology, and/or a star topology.The example system includes the first network including a first virtuallocal area network (VLAN), and the second network including a secondVLAN.

The example system includes the CND provided as a first portion in afirst location of the vehicle, and as a second portion in a secondlocation of the vehicle. The example system further includes the firstportion of the CND positioned in a first risk exposure profile, and thesecond portion of the CND positioned in a second risk exposure profile,where the first risk exposure profile is distinct from the second riskexposure profile. Example and non-limiting distinctions between the riskexposure profiles include one or more of: a geometric distinction; anenvironmental distinction; a failure mode distinction; a likely risktype distinction; and/or a likely disturbance distinction.

The example system includes an external transmitter communicativelycoupled to the CND, and configured to, at least intermittently,communicate with an external device. The example system includes the CNDconfigured to regulate communications between end points of the firstnetwork zone and the external device, and between end points of thesecond network zone and the external device.

The example system includes a first vehicle controller on the firstnetwork zone, a second vehicle controller on the second network zone,and a network redundancy circuit that selectively provides a regulationcontrol command, where the CND if further configured to adjustregulating communications between the first network zone and the secondnetwork zone in response to the regulation control command. Example andnon-limiting regulation control commands include one or more of: anoff-nominal condition corresponding to the first vehicle controller; aloss of a data element relating to the first vehicle controller; and/ora lost control function of the first vehicle controller. Example andnon-limiting adjustments to the regulating communications include one ormore operations such as: providing an alternate data element to thefirst vehicle controller; providing a data element corresponding to thelost control function to the second vehicle controller; and/or providinga data value ordinarily available on the first network zone to thesecond network zone. An example adjustment to the regulatingcommunications includes suppressing a communication of a data valueordinarily available on the first network zone in response to the lostcontrol function of the first vehicle controller. The example systemincludes providing the data value ordinarily available on the firstnetwork zone to the second network zone as a processed data value to thesecond vehicle controller. The lost control function includes one ormore or: a whole or partial loss of a control function nominallyperformed by the first vehicle controller; a lost communication with anend point of the first network zone; a loss of function of the firstvehicle controller; and/or a loss of communication with the firstvehicle controller.

The example system includes the first vehicle controller positioned in afirst risk exposure profile, and the second vehicle controllerpositioned in a second risk exposure profile, where the first riskexposure profile and the second risk exposure profile, where the firstrisk exposure profile is distinct from the second risk exposure profile.Example and non-limiting distinctions between the risk exposure profilesinclude one or more of: a geometric distinction; an environmentaldistinction; a failure mode distinction; a likely risk type distinction;and/or a likely disturbance distinction.

Certain alternative and/or additional regulation control commandsinclude one or more of: an off-nominal condition corresponding to thefirst network zone; a loss of communication between at least one endpoint of the first network zone and the first network zone; a physicalfailure of at least a portion of the first network zone; and a bandwidthlimitation of the first network zone. Example and non-limitingadjustments to the regulating communications include one or more of:routing at least one communication from the first network zone to thesecond network zone; repeating at least one communication from the firstnetwork zone to the second network zone; shifting at least one end pointfrom the first network zone to the second network zone; shifting and/orrepeating relevant communications with the at least one end point fromthe first network zone to the second network zone; and/or shiftingand/or repeating relevant communications with the at least one end pointfrom the second network zone to the first network zone.

The example system includes a vehicle controller on the first networkzone, and the CND at least partially co-located with the vehiclecontroller.

The example system includes a first portion of the CND co-located withthe vehicle controller, where the first portion includes non-transientcomputer readable instructions configured to, when executed by a processof the vehicle controller, perform at least a portion of the operationsof regulating the communications.

The example system includes a first portion of the CND co-located withthe vehicle controller, where the first portion includes an Ethernetswitch, where the first network zone includes an Ethernet network, wherecommunications between end points of the second network zone and thefirst network zone are routed through the Ethernet switch, and where theEthernet switch is positioned within a housing with the vehiclecontroller, and/or positioned on a same board with the vehiclecontroller.

The example system includes a first portion of the CND co-located withthe vehicle controller, where the first portion includes a configurableedge gateway (CEG), and where communications between and points of thefirst network zone and the second network zone are routed through theCEG, and where the CEG is positioned within a housing with the vehiclecontroller, and/or positions on a same board with the vehiclecontroller.

The example system includes a second vehicle controller on the secondnetwork zone, where the CND includes a first portion co-located with thevehicle controller, and a second portion co-located with the secondvehicle controller. Each of the first portion and the second portion ofthe CND may include one or more of: an Ethernet switch; a configurableedge gateway (CEG); and/or non-transient computer readable instructionsconfigured to, when executed by a process of the respective vehiclecontroller, perform at least a portion of the operations of regulatingthe communications. Each of the first portion and the second portion ofthe CND may be positioned within a housing of the respective vehiclecontroller, and/or on a same board with the respective vehiclecontroller.

The methods and systems described herein may be deployed in part or inwhole through a machine having a computer, computing device, processor,circuit, and/or server that executes computer readable instructions,program codes, instructions, and/or includes hardware configured tofunctionally execute one or more operations of the methods and systemsherein. The terms computer, computing device, processor, circuit, and/orserver, (“computing device”) as utilized herein, should be understoodbroadly.

An example computing device includes a computer of any type, capable toaccess instructions stored in communication thereto such as upon anon-transient computer readable medium, whereupon the computer performsoperations of the computing device upon executing the instructions. Incertain embodiments, such instructions themselves comprise a computingdevice. Additionally or alternatively, a computing device may be aseparate hardware device, one or more computing resources distributedacross hardware devices, and/or may include such aspects as logicalcircuits, embedded circuits, sensors, actuators, input and/or outputdevices, network and/or communication resources, memory resources of anytype, processing resources of any type, and/or hardware devicesconfigured to be responsive to determined conditions to functionallyexecute one or more operations of systems and methods herein.

Network and/or communication resources include, without limitation,local area network, wide area network, wireless, internet, or any otherknown communication resources and protocols. Example and non-limitinghardware and/or computing devices include, without limitation, a generalpurpose computer, a server, an embedded computer, a mobile device, avirtual machine, and/or an emulated computing device. A computing devicemay be a distributed resource included as an aspect of several devices,included as an interoperable set of resources to perform describedfunctions of the computing device, such that the distributed resourcesfunction together to perform the operations of the computing device. Incertain embodiments, each computing device may be on separate hardware,and/or one or more hardware devices may include aspects of more than onecomputing device, for example as separately executable instructionsstored on the device, and/or as logically partitioned aspects of a setof executable instructions, with some aspects comprising a part of oneof a first computing device, and some aspects comprising a part ofanother of the computing devices.

A computing device may be part of a server, client, networkinfrastructure, mobile computing platform, stationary computingplatform, or other computing platform. A processor may be any kind ofcomputational or processing device capable of executing programinstructions, codes, binary instructions and the like. The processor maybe or include a signal processor, digital processor, embedded processor,microprocessor or any variant such as a co-processor (math co-processor,graphic co-processor, communication co-processor and the like) and thelike that may directly or indirectly facilitate execution of programcode or program instructions stored thereon. In addition, the processormay enable execution of multiple programs, threads, and codes. Thethreads may be executed simultaneously to enhance the performance of theprocessor and to facilitate simultaneous operations of the application.By way of implementation, methods, program codes, program instructionsand the like described herein may be implemented in one or more threads.The thread may spawn other threads that may have assigned prioritiesassociated with them; the processor may execute these threads based onpriority or any other order based on instructions provided in theprogram code. The processor may include memory that stores methods,codes, instructions and programs as described herein and elsewhere. Theprocessor may access a storage medium through an interface that maystore methods, codes, and instructions as described herein andelsewhere. The storage medium associated with the processor for storingmethods, programs, codes, program instructions or other type ofinstructions capable of being executed by the computing or processingdevice may include but may not be limited to one or more of a CD-ROM,DVD, memory, hard disk, flash drive, RAM, ROM, cache and the like.

A processor may include one or more cores that may enhance speed andperformance of a multiprocessor. In embodiments, the process may be adual core processor, quad core processors, other chip-levelmultiprocessor and the like that combine two or more independent cores(called a die).

The methods and systems described herein may be deployed in part or inwhole through a machine that executes computer readable instructions ona server, client, firewall, gateway, hub, router, or other such computerand/or networking hardware. The computer readable instructions may beassociated with a server that may include a file server, print server,domain server, internet server, intranet server and other variants suchas secondary server, host server, distributed server and the like. Theserver may include one or more of memories, processors, computerreadable transitory and/or non-transitory media, storage media, ports(physical and virtual), communication devices, and interfaces capable ofaccessing other servers, clients, machines, and devices through a wiredor a wireless medium, and the like. The methods, programs, or codes asdescribed herein and elsewhere may be executed by the server. Inaddition, other devices required for execution of methods as describedin this application may be considered as a part of the infrastructureassociated with the server.

The server may provide an interface to other devices including, withoutlimitation, clients, other servers, printers, database servers, printservers, file servers, communication servers, distributed servers, andthe like. Additionally, this coupling and/or connection may facilitateremote execution of instructions across the network. The networking ofsome or all of these devices may facilitate parallel processing ofprogram code, instructions, and/or programs at one or more locationswithout deviating from the scope of the disclosure. In addition, all thedevices attached to the server through an interface may include at leastone storage medium capable of storing methods, program code,instructions, and/or programs. A central repository may provide programinstructions to be executed on different devices. In thisimplementation, the remote repository may act as a storage medium formethods, program code, instructions, and/or programs.

The methods, program code, instructions, and/or programs may beassociated with a client that may include a file client, print client,domain client, internet client, intranet client and other variants suchas secondary client, host client, distributed client and the like. Theclient may include one or more of memories, processors, computerreadable transitory and/or non-transitory media, storage media, ports(physical and virtual), communication devices, and interfaces capable ofaccessing other clients, servers, machines, and devices through a wiredor a wireless medium, and the like. The methods, program code,instructions, and/or programs as described herein and elsewhere may beexecuted by the client. In addition, other devices required forexecution of methods as described in this application may be consideredas a part of the infrastructure associated with the client.

The client may provide an interface to other devices including, withoutlimitation, servers, other clients, printers, database servers, printservers, file servers, communication servers, distributed servers, andthe like. Additionally, this coupling and/or connection may facilitateremote execution of methods, program code, instructions, and/or programsacross the network. The networking of some or all of these devices mayfacilitate parallel processing of methods, program code, instructions,and/or programs at one or more locations without deviating from thescope of the disclosure. In addition, all the devices attached to theclient through an interface may include at least one storage mediumcapable of storing methods, program code, instructions, and/or programs.A central repository may provide program instructions to be executed ondifferent devices. In this implementation, the remote repository may actas a storage medium for methods, program code, instructions, and/orprograms.

The methods and systems described herein may be deployed in part or inwhole through network infrastructures. The network infrastructure mayinclude elements such as computing devices, servers, routers, hubs,firewalls, clients, personal computers, communication devices, routingdevices and other active and passive devices, modules, and/or componentsas known in the art. The computing and/or non-computing device(s)associated with the network infrastructure may include, apart from othercomponents, a storage medium such as flash memory, buffer, stack, RAM,ROM and the like. The methods, program code, instructions, and/orprograms described herein and elsewhere may be executed by one or moreof the network infrastructural elements.

The methods, program code, instructions, and/or programs describedherein and elsewhere may be implemented on a cellular network havingmultiple cells. The cellular network may either be frequency divisionmultiple access (FDMA) network or code division multiple access (CDMA)network. The cellular network may include mobile devices, cell sites,base stations, repeaters, antennas, towers, and the like.

The methods, program code, instructions, and/or programs describedherein and elsewhere may be implemented on or through mobile devices.The mobile devices may include navigation devices, cell phones, mobilephones, mobile personal digital assistants, laptops, palmtops, netbooks,pagers, electronic books readers, music players and the like. Thesedevices may include, apart from other components, a storage medium suchas a flash memory, buffer, RAM, ROM and one or more computing devices.The computing devices associated with mobile devices may be enabled toexecute methods, program code, instructions, and/or programs storedthereon. Alternatively, the mobile devices may be configured to executeinstructions in collaboration with other devices. The mobile devices maycommunicate with base stations interfaced with servers and configured toexecute methods, program code, instructions, and/or programs. The mobiledevices may communicate on a peer to peer network, mesh network, orother communications network. The methods, program code, instructions,and/or programs may be stored on the storage medium associated with theserver and executed by a computing device embedded within the server.The base station may include a computing device and a storage medium.The storage device may store methods, program code, instructions, and/orprograms executed by the computing devices associated with the basestation.

The methods, program code, instructions, and/or programs may be storedand/or accessed on machine readable transitory and/or non-transitorymedia that may include: computer components, devices, and recordingmedia that retain digital data used for computing for some interval oftime; semiconductor storage known as random access memory (RAM); massstorage typically for more permanent storage, such as optical discs,forms of magnetic storage like hard disks, tapes, drums, cards and othertypes; processor registers, cache memory, volatile memory, non-volatilememory; optical storage such as CD, DVD; removable media such as flashmemory (e.g. USB sticks or keys), floppy disks, magnetic tape, papertape, punch cards, standalone RAM disks, Zip drives, removable massstorage, off-line, and the like; other computer memory such as dynamicmemory, static memory, read/write storage, mutable storage, read only,random access, sequential access, location addressable, fileaddressable, content addressable, network attached storage, storage areanetwork, bar codes, magnetic ink, and the like.

Certain operations described herein include interpreting, receiving,and/or determining one or more values, parameters, inputs, data, orother information (“receiving data”). Operations to receive datainclude, without limitation: receiving data via a user input; receivingdata over a network of any type; reading a data value from a memorylocation in communication with the receiving device; utilizing a defaultvalue as a received data value; estimating, calculating, or deriving adata value based on other information available to the receiving device;and/or updating any of these in response to a later received data value.In certain embodiments, a data value may be received by a firstoperation, and later updated by a second operation, as part of thereceiving a data value. For example, when communications are down,intermittent, or interrupted, a first receiving operation may beperformed, and when communications are restored an updated receivingoperation may be performed.

Certain logical groupings of operations herein, for example methods orprocedures of the current disclosure, are provided to illustrate aspectsof the present disclosure. Operations described herein are schematicallydescribed and/or depicted, and operations may be combined, divided,re-ordered, added, or removed in a manner consistent with the disclosureherein. It is understood that the context of an operational descriptionmay require an ordering for one or more operations, and/or an order forone or more operations may be explicitly disclosed, but the order ofoperations should be understood broadly, where any equivalent groupingof operations to provide an equivalent outcome of operations isspecifically contemplated herein. For example, if a value is used in oneoperational step, the determining of the value may be required beforethat operational step in certain contexts (e.g. where the time delay ofdata for an operation to achieve a certain effect is important), but maynot be required before that operation step in other contexts (e.g. whereusage of the value from a previous execution cycle of the operationswould be sufficient for those purposes). Accordingly, in certainembodiments an order of operations and grouping of operations asdescribed is explicitly contemplated herein, and in certain embodimentsre-ordering, subdivision, and/or different grouping of operations isexplicitly contemplated herein.

The methods and systems described herein may transform physical and/oror intangible items from one state to another. The methods and systemsdescribed herein may also transform data representing physical and/orintangible items from one state to another.

The methods and/or processes described above, and steps thereof, may berealized in hardware, program code, instructions, and/or programs or anycombination of hardware and methods, program code, instructions, and/orprograms suitable for a particular application. The hardware may includea dedicated computing device or specific computing device, a particularaspect or component of a specific computing device, and/or anarrangement of hardware components and/or logical circuits to performone or more of the operations of a method and/or system. The processesmay be realized in one or more microprocessors, microcontrollers,embedded microcontrollers, programmable digital signal processors orother programmable device, along with internal and/or external memory.The processes may also, or instead, be embodied in an applicationspecific integrated circuit, a programmable gate array, programmablearray logic, or any other device or combination of devices that may beconfigured to process electronic signals. It will further be appreciatedthat one or more of the processes may be realized as a computerexecutable code capable of being executed on a machine readable medium.

The computer executable code may be created using a structuredprogramming language such as C, an object oriented programming languagesuch as C++, or any other high-level or low-level programming language(including assembly languages, hardware description languages, anddatabase programming languages and technologies) that may be stored,compiled or interpreted to run on one of the above devices, as well asheterogeneous combinations of processors, processor architectures, orcombinations of different hardware and computer readable instructions,or any other machine capable of executing program instructions.

Thus, in one aspect, each method described above and combinationsthereof may be embodied in computer executable code that, when executingon one or more computing devices, performs the steps thereof. In anotheraspect, the methods may be embodied in systems that perform the stepsthereof, and may be distributed across devices in a number of ways, orall of the functionality may be integrated into a dedicated, standalonedevice or other hardware. In another aspect, the means for performingthe steps associated with the processes described above may include anyof the hardware and/or computer readable instructions described above.All such permutations and combinations are intended to fall within thescope of the present disclosure.

While the disclosure has been disclosed in connection with certainembodiments shown and described in detail, various modifications andimprovements thereon will become readily apparent to those skilled inthe art. Accordingly, the spirit and scope of the present disclosure isnot to be limited by the foregoing examples, but is to be understood inthe broadest sense allowable by law.

What is claimed is:
 1. A system comprising: a vehicle having a firstnetwork and a second network; a first device on the first network; and aconverged network device (CND) interposed between the first network andthe second network and structured to facilitate communications betweenthe first device and the second network; wherein the first network is ofa different type than the second network.
 2. The system of claim 1further comprising: a second device on the second network and structuredto communicate with the first device via the CND.
 3. The system of claim1 further comprising: an external device communicatively coupled to theCND, wherein the external device is structured to adjust a configurationof the CND.
 4. The system of claim 1, wherein at least one of the firstnetwork and/or the second network is a Controller Area Network (CAN)based network.
 5. The system of claim 1, wherein at least one of thefirst network and/or the second network is an Ethernet based network. 6.The system of claim 5, wherein the Ethernet based network comprises adata bus architecture.
 7. The system of claim 1, wherein the firstnetwork is a Controller Area Network (CAN) based network and the secondnetwork is an Ethernet based network.
 8. The system of claim 7, whereinthe CND comprises: a communication device structured to access the CANbased network; an Ethernet switch structured to access to the Ethernetbased network; and wherein the communication device provides a messageto the Ethernet switch in response to a corresponding message on the CANbased network.
 9. The system of claim 8, wherein the communicationdevice is structured to provide the message to the Ethernet switch as anEthernet message including at least one encapsulated CAN message basedon the corresponding message on the CAN based network.
 10. The system ofclaim 9, wherein the at least one encapsulated CAN message includes morethan one encapsulated CAN message.
 11. The system of claim 8, whereinthe communication device is positioned in a first housing, and whereinthe Ethernet switch is positioned in a second housing.
 12. The system ofclaim 8, wherein the communication device and the Ethernet switch arepositioned in a single housing.
 13. The system of claim 7, wherein theCND comprises: a communication device structured to access the CAN basednetwork; an Ethernet switch structured to access to the Ethernet basednetwork; and wherein the communication device receives a message fromthe Ethernet switch in response to a corresponding message on theEthernet based network.
 14. The system of claim 13, wherein thecommunication device is structured to receive the message from theEthernet switch as an Ethernet message including at least oneencapsulated CAN message based on the corresponding message on theEthernet based network.
 15. The system of claim 14, wherein the at leastone encapsulated CAN message includes more than one encapsulated CANmessage.
 16. The system of claim 13, wherein the communication device ispositioned in a first housing, and wherein the Ethernet switch ispositioned in a second housing.
 17. The system of claim 13, wherein thecommunication device and the Ethernet switch are positioned in a singlehousing.
 18. An apparatus comprising: a first network interface circuitstructured to interpret a first network data set having a first networkformat; a translation circuit structured to determine a message valuefrom the first network data set and to encode the message value in asecond network data set having a second network format; and a secondnetwork interface circuit structured to transmit the second network dataset; wherein: the first network format and the second network format arevehicle data formats; and the first network format is different than thesecond network format.
 19. The apparatus of claim 18 further comprising:a configuration circuit structured to configure the first networkinterface circuit, the translation circuit, and/or the second networkinterface circuit, responsive to a configuration command value from adevice external to a vehicle, the vehicle including the first networkinterface circuit and the second network interface circuit.
 20. Theapparatus of claim 19, wherein the configuration command value comprisesat least one value selected from the values consisting of: a samplingrate value; a payload processing value; a timestamp value; a metadatavalue; a target device for the message value from the first network dataset, wherein the target device comprises a device on the vehicle to sendand/or receive the message value; and an encapsulation description forthe message value.
 21. The apparatus of claim 18, wherein the firstnetwork format and/or the second network format is Controller AreaNetwork (CAN) based.
 22. The apparatus of claim 18, wherein the firstnetwork format and/or the second network format is Ethernet based. 23.The apparatus of claim 18, wherein one of the first network format orthe second network format is Controller Area Network (CAN) based, andthe other of the first network format or the second network format isEthernet based.
 24. The apparatus of claim 23, wherein one or more CANmessages of the CAN based network can be carried in one Ethernet frameof the Ethernet based network.
 25. The apparatus of claim 18, whereinthe first network interface circuit and/or the second network interfacecircuit is integrated with a configurable edge gateway (CEG).
 26. Theapparatus of claim 18, wherein the first network interface circuitand/or the second network interface circuit is integrated with anEthernet switch.
 27. The apparatus of claim 18, wherein the firstnetwork interface circuit, the translation circuit, and/or the secondnetwork interface circuit, are compliant with the Motor IndustrySoftware Reliability Association standard and/or the AUTomotive OpenSystem ARchitecture standard.
 28. A method comprising: interpreting afirst network data set having a first network format for a first networkzone of a vehicle; determining a message value from the first networkdata set in response to interpreting the first network data set;encoding the message value in a second network data set having a secondnetwork format for a second network zone of the vehicle; andtransmitting the second network data set; wherein: the first networkformat and the second network format are vehicle data formats; and thefirst network format is different than the second network format. 29.The method of claim 28, further comprising adjusting a configuration ofat least one of the encoding or the transmitting in response to aconfiguration change from an external device.
 30. The method of claim28, further comprising: wherein the first network zone is a ControllerArea Network (CAN) based network, and wherein the second network zone isan Ethernet based network; and wherein the second network data setcomprises an Ethernet message corresponding to at least one CAN messageof the first network data set.
 31. The method of claim 30, whereinencoding the message value in the second network data set comprisesencapsulating the CAN message into the Ethernet message.
 32. The methodof claim 31, wherein encoding the message value further comprisesprocessing at least one of a payload or a frame portion of the CANmessage.
 33. The method of claim 31, wherein encoding the message valuefurther comprises performing at least one of up-sampling ordown-sampling the CAN message.
 34. The method of claim 30, wherein theat least one CAN message includes at least a first CAN message and asecond CAN message.